> The topic of localizable sentences is now closed on this mail list.
> Please take that topic elsewhere.
> Thank you.
May I please mention, with permission, that there is now a thread to discuss
the issue of translations and their context that was mentioned?
https://community.serif.com/discussi
On Tue, 12 Jun 2018 19:49:10 +0200, Mark Davis ☕️ via Unicode wrote:
[…]
> People interested in this topic should
> (a) start up their own project somewhere else,
> (b) take discussion of it off this list,
> (c) never bring it up again on this list.
Thank you for letting us know. I apologize for
The topic of localizable sentences is now closed on this mail list.
Please take that topic elsewhere.
Thank you.
On 6/12/2018 10:49 AM, Mark Davis âï¸ via Unicode wrote:
> That is often a viable approach. But proponents shouldn't get the wrong
impression. I think the chance of anything resemb
On Mon, Jun 11, 2018 at 8:32 AM, William_J_G Overington <
wjgo_10...@btinternet.com> wrote:
> Steven R. Loomis wrote:
>
> >Marcel,
> > The idea is not necessarily without merit. However, CLDR does not
> usually expand scope just because of a suggestion.
> I usually recommend creating a new projec
Steven wrote:
> I usually recommend creating a new project first...
That is often a viable approach. But proponents shouldn't get the wrong
impression. I think the chance of anything resembling the "localized
sentences" / "international message components" have zero chance of being
adopted by U
> ISO 15924 is and ISO standard. Aspects of its content may be mirrored in
other places, but “moving its content” to CLDR makes no sense.
Fully agreed.
For what it's worth, I reopened a bug of Roozbeh's
https://unicode.org/cldr/trac/ticket/827?#comment:9 to make sure the ISO
15924 French content
On 6/12/2018 7:58 AM, Michael Everson
via Unicode wrote:
Marcel,
You have put words into my mouth. Please don’t. Your description of what I said is NOT accurate.
On 12 Jun 2018, at 03:53, Marcel Schneider via Unicode wrote:
And in this thread I
CLDR already has localized script names. The English is taken from ISO
15924. https://cldr-ref.unicode.org/cldr-apps/v#/fr/Scripts/
On Tue, Jun 12, 2018 at 8:20 AM, Marcel Schneider via Unicode <
unicode@unicode.org> wrote:
> On Tue, 12 Jun 2018 15:58:09 +0100, Michael Everson via Unicode wrote:
All right, if you want a clear explanation.
Yes, I think the ISO 8859-4 character names for the Latvian letters were
mistaken. Yes, I think that mapping them to decompositions with CEDILLA rather
than COMMA BELOW was a mistake. Evidently some felt that the normative mapping
was important. This
On Tue, 12 Jun 2018 15:58:09 +0100, Michael Everson via Unicode wrote:
>
> Marcel,
>
> You have put words into my mouth. Please don’t. Your description of what I
> said is NOT accurate.
>
> > On 12 Jun 2018, at 03:53, Marcel Schneider via Unicode wrote:
> >
> > And in this thread I wanted to
Marcel,
You have put words into my mouth. Please don’t. Your description of what I said
is NOT accurate.
> On 12 Jun 2018, at 03:53, Marcel Schneider via Unicode
> wrote:
>
> And in this thread I wanted to demonstrate that by focusing on the wrong
> priorities, i.e. legacy character names i
William,
On 12/06/18 12:26, William_J_G Overington wrote:
>
> Hi Marcel
>
> > I don’t fully disagree with Asmus, as I suggested to make available
> > localizable (and effectively localized) libraries of message components,
> > rather than of entire messages.
>
> Could you possibly give some
Hi Marcel
> I don’t fully disagree with Asmus, as I suggested to make available
> localizable (and effectively localized) libraries of message components,
> rather than of entire messages.
Could you possibly give some examples of the message components to which you
refer please?
Asmus wrote:
On Mon, 11 Jun 2018 16:32:45 +0100 (BST), William_J_G Overington via Unicode
wrote:
[…]
> Asmus Freytag wrote:
>
> > If you tried to standardize all error messages even in one language you
> > would never arrive at something that would be universally useful.
>
> Well that is a big "If". One can
Steven R. Loomis wrote:
>Marcel,
> The idea is not necessarily without merit. However, CLDR does not usually
> expand scope just because of a suggestion.
I usually recommend creating a new project first - gathering data, looking at
and talking to projects to ascertain the usefulness of common m
; peter...@microsoft.com;
richard.wording...@ntlworld.com
Cc: unicode@unicode.org
Subject: Re: The Unicode Standard and ISO
Steven R. Loomis wrote:
>Marcel,
> The idea is not necessarily without merit. However, CLDR does not usually
> expand scope just because of a suggestion.
I usually
> > From the outset, Unicode and the US national body tried repeatedly to
> > engage with SC35 and SC35/WG5,
[…]
> As a reminder: The actual SC35 is in total disconnect from the same SC35 as
> it was from the mid-eighties to mid-nineties and beyond.
Edit: ISO/IEC JTC1 SC35 was founded in 1999. (
ay be pleased to know that I try to keep helping do our best.
Thank you everyone.
Best regards,
Marcel
>
>
> Peter
>
>
> From: Unicode On Behalf Of Mark Davis ?? via Unicode
> Sent: Thursday, June 7, 2018 6:20 AM
> To: Marcel Schneider
> Cc: UnicodeMailing
>
led to cooperate or is is dropping the
ball with regard to locale data and ISO is simply uninformed.
Peter
From: Unicode On Behalf Of Mark Davis ?? via
Unicode
Sent: Thursday, June 7, 2018 6:20 AM
To: Marcel Schneider
Cc: UnicodeMailing
Subject: Re: The Unicode Standard and ISO
A few
On Sat, 9 Jun 2018 21:21:40 -0700, Steven R. Loomis via Unicode wrote:
>
> Marcel,
> The idea is not necessarily without merit. However, CLDR does not usually
>expand scope just because of a suggestion.
>
> I usually recommend creating a new project first - gathering data, looking at
> and talki
On Sat, 9 Jun 2018 12:56:28 -0700, Asmus Freytag via Unicode wrote:
[…]
> It's pushing this kind of impractical scheme that gives standardizers a bad
> name.
>
> Especially if it is immediately tied to governmental procurement, forcing
> people to adopt it (or live with it)
> whether it provide
Marcel,
The idea is not necessarily without merit. However, CLDR does not usually
expand scope just because of a suggestion.
I usually recommend creating a new project first - gathering data, looking
at and talking to projects to ascertain the usefulness of common messages..
one of the barriers
On Sat, 9 Jun 2018 12:56:28 -0700, Asmus Freytag via Unicode wrote:
>
> On 6/9/2018 12:01 PM, Marcel Schneider via Unicode wrote:
> > Still a computer should be understandable off-line, so CLDR providing a
> > standard library of error messages could be
> > appreciated by the industry.
>
> The k
On 6/9/2018 12:01 PM, Marcel Schneider
via Unicode wrote:
Still a computer should be understandable off-line, so CLDR providing a standard library of error messages could be
appreciated by the industry.
The kind of translations that CLDR accumulates,
018 7:49 PM
> To: Marcel Schneider
> Cc: UnicodeMailingList
> Subject: Re: The Unicode Standard and ISO
2018-06-09 17:22 GMT+02:00 Marcel Schneider via Unicode :
On Sat, 9 Jun 2018 09:47:01 +0100, Richard Wordingham via Unicode wrote:
> >
> > On Sat, 9 Jun 2018 0
Of Philippe Verdy
via Unicode
Sent: Saturday, June 09, 2018 7:49 PM
To: Marcel Schneider
Cc: UnicodeMailingList
Subject: Re: The Unicode Standard and ISO
2018-06-09 17:22 GMT+02:00 Marcel Schneider via Unicode
mailto:unicode@unicode.org>>:
On Sat, 9 Jun 2018 09:47:01 +0100, Richard Word
2018-06-09 17:22 GMT+02:00 Marcel Schneider via Unicode :
> On Sat, 9 Jun 2018 09:47:01 +0100, Richard Wordingham via Unicode wrote:
> >
> > On Sat, 9 Jun 2018 08:23:33 +0200 (CEST)
> > Marcel Schneider via Unicode wrote:
> >
> > > > Where there is opportunity for productive sync and merging with
On Sat, 9 Jun 2018 09:47:01 +0100, Richard Wordingham via Unicode wrote:
>
> On Sat, 9 Jun 2018 08:23:33 +0200 (CEST)
> Marcel Schneider via Unicode wrote:
>
> > > Where there is opportunity for productive sync and merging with is
> > > glibc. We have had some discussions, but more needs to be d
I just see the WG2 as a subcomity where governements may just check their
practices and make minimum recommendations. Most governements are in fact
very late to adopt the industry standards that evolve fast, and they just
want to reduce the frequency of necessary changes jsut to enterinate what
see
On Sat, 9 Jun 2018 08:23:33 +0200 (CEST)
Marcel Schneider via Unicode wrote:
> > Where there is opportunity for productive sync and merging with is
> > glibc. We have had some discussions, but more needs to be done-
> > especially a lot of tooling work. Currently many bug reports are
> > duplicat
On Fri, 8 Jun 2018 09:20:09 -0700, Steven R. Loomis via Unicode wrote:
[…]
> But, it sounds like the CLDR process was successful in this case. Thank you
>for contributing.
You are welcome, but thanks are due to the actual corporate contributors.
[…]
> Actually, I think the particular data item
On Fri, 8 Jun 2018 20:45:26 +0200
Philippe Verdy via Unicode wrote:
> 2018-06-08 19:41 GMT+02:00 Richard Wordingham via Unicode <
> unicode@unicode.org>:
> The way tailoring is designed in CLDR using only data used by a
> generic algorithm, and not custom algorithm is not the only way to
> col
On Fri, 8 Jun 2018 14:14:51 -0700
"Steven R. Loomis via Unicode" wrote:
> > But the consortium has formally dropped the commitment to DUCET in
> > CLDR. Even when restricted to strings of assigned characters, the
> > CLDR and ICU no longer make the effort to support the DUCET
> > collation.
>
On 6/8/2018 2:28 PM, Marcel Schneider
via Unicode wrote:
On Fri, 8 Jun 2018 13:33:20 -0700, Asmus Freytag via Unicode wrote:
[…]
There's no value added in creating "mirrors" of something that is successfully being devel
On Fri, 8 Jun 2018 16:54:20 -0400, Tom Gewecke via Unicode wrote:
>
> > On Jun 8, 2018, at 9:52 AM, Marcel Schneider via Unicode wrote:
> >
> > People relevant to projects for French locale do trace the borderline of
> > applicability wider
> > than do those people who are closerly tied to Uni
On Fri, 8 Jun 2018 13:33:20 -0700, Asmus Freytag via Unicode wrote:
>
[…]
> There's no value added in creating "mirrors" of something that is
> successfully being developed and maintained under a different umbrella.
Wouldn’t the same be true for ISO/IEC 10646? It has no value added neither, and
Richard,
> But the consortium has formally dropped the commitment to DUCET in CLDR.
> Even when restricted to strings of assigned characters, the
> CLDR and ICU no longer make the effort to support the DUCET
> collation.
CLDR is not a collation implementation, it is a data repository with
associ
> On Jun 8, 2018, at 9:52 AM, Marcel Schneider via Unicode
> wrote:
>
> People relevant to projects for French locale do trace the borderline of
> applicability wider
> than do those people who are closerly tied to Unicode‐related projects.
Could you give a concrete example or two of what
On 6/8/2018 5:01 AM, Michael Everson
via Unicode wrote:
and achieving a fullscale merger with ISO/IEC 15897, after which the valid data stay hosted entirely in CLDR, and ISO/IEC 15897 would be its ISO mirror.
I wonder if Mark Davis will be qu
2018-06-08 19:41 GMT+02:00 Richard Wordingham via Unicode <
unicode@unicode.org>:
> On Fri, 8 Jun 2018 13:40:21 +0200
> Mark Davis ☕️ wrote:
>
> > Mark
> >
> > On Fri, Jun 8, 2018 at 10:06 AM, Richard Wordingham via Unicode <
> > unicode@unicode.org> wrote:
> >
> > > On Fri, 8 Jun 2018 05:32:51 +
On Fri, 8 Jun 2018 13:40:21 +0200
Mark Davis ☕️ wrote:
> Mark
>
> On Fri, Jun 8, 2018 at 10:06 AM, Richard Wordingham via Unicode <
> unicode@unicode.org> wrote:
>
> > On Fri, 8 Jun 2018 05:32:51 +0200 (CEST)
> > Marcel Schneider via Unicode wrote:
> >
> > > Thank you for confirming. All w
Marcel,
On Fri, Jun 8, 2018 at 6:52 AM, Marcel Schneider via Unicode <
unicode@unicode.org> wrote:
>
> What got me started is that before even I requested a submitter ID (and
> the reason why I’ve requested one),
> "Characters | Category | Label | keycap" remained untranslated, i.e. its
> French t
On Fri, 8 Jun 2018 08:50:28 -0400, Tom Gewecke via Unicode wrote:
>
>
> > On Jun 7, 2018, at 11:32 PM, Marcel Schneider via Unicode wrote:
> >
> > What bothered me ... is that the registration of the French locale in CLDR
> > is
> > still surprisingly incomplete
>
> Could you provide an exam
On Fri, 8 Jun 2018 13:06:18 +0200, Mark Davis ☕️ via Unicode wrote:
>
> Where are you getting your "facts"? Among many unsubstantiated or ambiguous
> claims in that very long sentence:
>
> > "French locale in CLDR is still surprisingly incomplete".
>
> For each release, the data collected for th
> On Jun 7, 2018, at 11:32 PM, Marcel Schneider via Unicode
> wrote:
>
> What bothered me ... is that the registration of the French locale in CLDR is
> still surprisingly incomplete
Could you provide an example or two?
On 8 June 2018 at 13:01, Michael Everson via Unicode
wrote:
>
> I wonder if Mark Davis will be quick to agree with me 😅 when I say that
> ISO/IEC 15897 has no use and should be withdrawn.
It was reviewed and confirmed in 2017, so the next systematic review
won't be until 2022. And as the standar
On 8 Jun 2018, at 04:32, Marcel Schneider via Unicode
wrote:
> the registration of the French locale in CLDR is still surprisingly
> incomplete despite the meritorious efforts made by the actual contributors
Nothing prevents people from working to complete the French locale in CLDR.
Synchroni
On 7 Jun 2018, at 20:13, Marcel Schneider via Unicode
wrote:
> On Fri, 18 May 2018 00:29:36 +0100, Michael Everson via Unicode responded:
>>
>> It would be great if mutual synchronization were considered to be of benefit.
>> Some of us in SC2 are not happy that the Unicode Consortium has publis
Mark
On Fri, Jun 8, 2018 at 10:06 AM, Richard Wordingham via Unicode <
unicode@unicode.org> wrote:
> On Fri, 8 Jun 2018 05:32:51 +0200 (CEST)
> Marcel Schneider via Unicode wrote:
>
> > Thank you for confirming. All witnesses concur to invalidate the
> > statement about uniqueness of ISO/IEC 106
Where are you getting your "facts"? Among many unsubstantiated or ambiguous
claims in that very long sentence:
1. "French locale in CLDR is still surprisingly incomplete".
1. For each release, the data collected for the French locale is
complete to the bar we have set for Level=Mode
On Fri, 8 Jun 2018 05:32:51 +0200 (CEST)
Marcel Schneider via Unicode wrote:
> Thank you for confirming. All witnesses concur to invalidate the
> statement about uniqueness of ISO/IEC 10646 ‐ Unicode synchrony. —
> After being invented in its actual form, sorting was standardized
> simultaneously
On Fri, 8 Jun 2018 00:43:04 +0200, Philippe Verdy via Unicode wrote:
[cited mail]
>
> The "normative names" are in fact normative only as a forward reference
> to the ISO/IEC repertoire becaus it insists that these names are essential
> part
> of the stable encoding policy which was then integrate
On Thu, 7 Jun 2018 22:46:12 +0300, Erkki I. Kolehmainen via Unicode wrote:
>
> I cannot but fully agree with Mark and Michael.
>
> Sincerely
>
Thank you for confirming. All witnesses concur to invalidate the statement
about
uniqueness of ISO/IEC 10646 ‐ Unicode synchrony. — After being invent
2018-06-07 21:13 GMT+02:00 Marcel Schneider via Unicode :
> On Thu, 17 May 2018 22:26:15 +, Peter Constable via Unicode wrote:
> […]
> > Hence, from an ISO perspective, ISO 10646 is the only standard for which
> on-going
> > synchronization with Unicode is needed or relevant.
>
> This point of
: unicode Unicode Discussion
Aihe: Re: The Unicode Standard and ISO
On 7 Jun 2018, at 14:20, Mark Davis ☕️ via Unicode wrote:
>
> A few facts.
>
>> > ... Consortium refused till now to synchronize UCA and ISO/IEC 14651.
>
> ISO/IEC 14651 and Unicode have longstanding c
On Thu, 17 May 2018 22:26:15 +, Peter Constable via Unicode wrote:
[…]
> Hence, from an ISO perspective, ISO 10646 is the only standard for which
> on-going
> synchronization with Unicode is needed or relevant.
This point of view is fueled by the Unicode Standard being traditionally
thought
ISO14651
we can read that “This relationship between the two standards is similar to
that maintained between
the Unicode Standard and ISO/IEC 10646[,]” confusingly there seems to be no
related FAQ. Even more
confusingly, a straightforward question like “I was wondering which ISO
standards other tha
On 7 Jun 2018, at 14:20, Mark Davis ☕️ via Unicode wrote:
>
> A few facts.
>
>> > ... Consortium refused till now to synchronize UCA and ISO/IEC 14651.
>
> ISO/IEC 14651 and Unicode have longstanding cooperation. Ken Whistler could
> speak to the synchronization level in more detail, but the
A few facts.
> ... Consortium refused till now to synchronize UCA and ISO/IEC 14651.
ISO/IEC 14651 and Unicode have longstanding cooperation. Ken Whistler could
speak to the synchronization level in more detail, but the above statement
is inaccurate.
> ... For another part it [sync with ISO/IEC
On Thu, 17 May 2018 09:43:28 -0700, Asmus Freytag via Unicode wrote:
>
> On 5/17/2018 8:08 AM, Martinho Fernandes via Unicode wrote:
> > Hello,
> >
> > There are several mentions of synchronization with related standards in
> > unicode.org, e.g. in https://www.unicode.org/versions/index.html, and
It would be great if mutual synchronization were considered to be of benefit.
Some of us in SC2 are not happy that the Unicode Consortium has published
characters which are still under Technical ballot. And this did not happen only
once.
> On 17 May 2018, at 23:26, Peter Constable via Unicode
-
From: Unicode On Behalf Of Martinho Fernandes via
Unicode
Sent: Thursday, May 17, 2018 8:08 AM
To: unicode@unicode.org
Subject: The Unicode Standard and ISO
Hello,
There are several mentions of synchronization with related standards in
unicode.org, e.g. in https://www.unicode.org/versions
On 5/17/2018 8:08 AM, Martinho Fernandes via Unicode wrote:
Hello,
There are several mentions of synchronization with related standards in
unicode.org, e.g. in https://www.unicode.org/versions/index.html, and
https://www.unicode.org/faq/unicode_iso.html. However, all such mentions
never mention
Hello,
There are several mentions of synchronization with related standards in
unicode.org, e.g. in https://www.unicode.org/versions/index.html, and
https://www.unicode.org/faq/unicode_iso.html. However, all such mentions
never mention anything other than ISO 10646.
I was wondering which ISO stan
64 matches
Mail list logo
