;
<mailto:tfuji...@redhat.com <mailto:tfuji...@redhat.com>>>>
wrote:
Hi,
Do you have any chances to create a different version of
ja.xml of the Japanese emoji annotation?
http://unicode.org/cldr/trac/browse
Ah, yes. Sorry for my confusion.
One main purpose for the short names is for TTS, and for that I think
people felt that the reading was more useful. However, it would probably be
better for the keywords to have the normal spelling. You might consider
filing a ticket at http://unicode.org/cldr/trac
redhat.com
<mailto:tfuji...@redhat.com>>> wrote:
Hi,
Do you have any chances to create a different version of ja.xml of
the Japanese emoji annotation?
http://unicode.org/cldr/trac/browser/tags/latest/common/annotations/ja.xml
<http://u
I think he meant Kanji/Han ideographic by "committed string".
2017-03-27 19:04 GMT+09:00 Takao Fujiwara :
> On 03/27/17 18:48, Mark Davis ☕️-san wrote:
>
>> By "committed strings", you mean the hiragana phonetic reading?
>>
>
> Hiragana is used to the raw text of the phonetic reading by the Japan
Do you have any chances to create a different version of ja.xml of the
Japanese emoji annotation?
http://unicode.org/cldr/trac/browser/tags/latest/common/annotations/ja.xml
<http://unicode.org/cldr/trac/browser/tags/latest/common/annotations/ja.xml>
That file includes Hiragana only but
rowser/tags/latest/common/annotations/ja.xml
>
> That file includes Hiragana only but I'd need another file which has the
> committed strings, likes ja_convert.xml.
> E.g.
>男 | 男性 | シンボル
>
> instead of
>
>おとこ | だんせい | しんぼる
>
> I th
Hi,
Do you have any chances to create a different version of ja.xml of the Japanese
emoji annotation?
http://unicode.org/cldr/trac/browser/tags/latest/common/annotations/ja.xml
That file includes Hiragana only but I'd need another file which has the
committed strings, likes ja_conver
On 3/15/2016 7:42 AM, Doug Ewell wrote:
Asmus Freytag wrote:
• don't ask for additions or changes
Additions and changes to annotations are considered all the time.
Well, yes. I meant additions and chang
Asmus Freytag wrote:
>> • don't ask for additions or changes
>
> Additions and changes to annotations are considered all the time.
Well, yes. I meant additions and changes to the scope of the file.
--
Doug Ewell | http://ewellic.org | Thornton, CO 🇺🇸
. I am FAR more comfortable with that type of guideline:
• the data isn't normative (at least not all of it)
• the format isn't set in stone
• don't ask for additions or changes
Additions and changes to annotations are considered all the time.
There's just no implication tha
On 3/14/2016 11:33 AM, Janusz S. Bien wrote:
Quote/Cytat - Doug Ewell (pon, 14 mar 2016, 19:22:14):
Ken Whistler wrote:
The trick is this: the status of annotational data in NamesList.txt
is different than that of normative data like the code points, names,
formal name aliases, decomposition
Janusz S. Bień wrote:
>> • don't ask for additions or changes
>
> What about reporting possible mistakes?
I'd assume that egregious, demonstrable errors, such as misspelled
character names or incorrect individual code points, could be reported,
and anything beyond that probably should not.
--
Quote/Cytat - Doug Ewell (pon, 14 mar 2016, 19:22:14):
Ken Whistler wrote:
The trick is this: the status of annotational data in NamesList.txt
is different than that of normative data like the code points, names,
formal name aliases, decomposition mappings, and standardized
variation sequence
Ken Whistler wrote:
> The trick is this: the status of annotational data in NamesList.txt
> is different than that of normative data like the code points, names,
> formal name aliases, decomposition mappings, and standardized
> variation sequences.
I get that. I am FAR more comfortable with that
n mappings, and standardized variation sequences.
Annotations are -- well, annotational -- and there are no guarantees
about their completeness or stability, and so on. They emerge from a
kind of ongoing rugby scrum between the UTC members,
national body comments on 10646 amendments, public suggestio
insert additional data or annotations (with JSON or CSV/tabulated
formats, the number of columns is fixed, all columns must be fed at least
with an empty data, even if it is is not significant). Note that legacy
formats also have comments after hash signs, but many comments found at end
of data lines also h
ndard,
it's a non-starter.
There are explanations about character use that are only maintained in
the PDF of the core specification, where this information is packaged
in a way that can be understood by a human reader, but is not amenable
to be extracted by machine.
While the an
On Sun, 13 Mar 2016 13:03:20 -0600, Doug Ewell wrote:
> My point is that of J.S. Choi and Janusz Bień: the problem with
> declaring NamesList off-limits is that it does contain information that
> is either:
>
> • not available in any other UCD file, or
> • available, but only in comments (like t
My point is that of J.S. Choi and Janusz Bień: the problem with
declaring NamesList off-limits is that it does contain information that
is either:
• not available in any other UCD file, or
• available, but only in comments (like the MAS mappings), which aren't
supposed to be parsed either.
Ke
On Sun, 13 Mar 2016 07:55:24 +0100, Janusz S. Bień wrote:
> For this purpose he wrote also a converter from NamesList format to XML
That goes straight into the direction I suggested past year as a beta feedback
item[1], but I never thought that it could be so simple.
> I understand there is no
49 PM, "J. S. Choi" wrote:
>> One thing about NamesList.txt is that, as far as I have been able to
>> tell, it’s the only machine-readable, parseable source of those
>> annotations and cross-references.
[...]
> This is a different issue. The nameslist.txt is
Le chapitre 13 (14 en français) d'Unicode 3.0 portant sur les « zones
spéciales et caractères de formatage » a été traduit et annoté.
http://iquebec.ifrance.com/hapax/pdf/Chapitre-14.pdf
Les modifications apportées par Unicode 3.1 y ont été intégrées. Vous
remarquerez qu'il manque encore un glyp
22 matches
Mail list logo
