Hi dev, Hu, Jonathon, strange sender's address..
On Saturday, 2006-10-28 01:36:01 +0000, dev@openoffice.org wrote: > >If I understand correctly, technically spoken these are script types of > >existing languages. > > Technically, ASL is a language of its own, not a variant of English > (US). BlissSymbolics --- which I didn't ask about, because the Unicode > sequence is still being determined is in the same situation. The "language of its own" pointed me into the right direction. The solution for ASL will simply be its ISO/FDIS 639-3 code 'ase'. The language tag for BlissSymbolics would be undetermined, it seems. > [... Braille ...] > > nor does the ODF file format provide mechanisms for storing them. > > This will hopefully be solved in the next version of the standard. > > Is there a time frame for that? The next OASIS standard for ODF 1.2 is scheduled for September 2007. We definitely need a solution for at least script language subtags and variants, so IMHO that version MUST address these somehow. I'll pursue that. > >>* Submit a request for Braille as an language of its own, with one > >>request for each grade. [Or more likely, two requests for each grade > >>--- that allows for multi-lingual content in Braille.] > > >This could be a possibility, using RFC 3066 x-... private tags. However, > >there would be no connection to the underlying "real" language then, > >which I consider a major drawback. > > The connection to the Locale data of the underlying "real" language > might be an issue. OTOH, if a "reasonable" default locale can be set, > then it is "solvable". Not sure what you're referring with a reasonable default locale there, but from what I guess, in context of the x-something tags this is not possible. The script subtag would solve these problems in a technically clean manner, and the language and region parts of the locale would be unambiguous. > Would it be possible for the default Braille locale to be changed > according to the language/locale of the User Interface? > EG: > An Afrikaans default Braille Locale, for an Afrikaans User Interface; > An English (UK) default Braille Locale, for an English *UK) User Interface; > An Arabic default Braille Locale, for an Arabic User Interface; Yes, with a script subtag that would be af-ZA => af-Brai-ZA, en-GB => en-Brai-GB, ... I do not mention the implementation side here, there may be at least a dozens issues to be solved before anything would start working.. > >Also Moon and ASL look like script types to me, if I'm not mislead. > > ASL is a language in its own right. The association with English is > simply because it was developed in the US. Quite some reading at Wikipedia: http://en.wikipedia.org/wiki/American_Sign_Language > Moon is a writing system, that has been transcribed for roughly 400 or > so languages. http://en.wikipedia.org/wiki/Moon_type Definitely looks like a script type. > The only language for which it currently has extensive > use is English (UK). As with Braille, a private tag could be used. > I doubt anybody would have objections to Moon (at least initially) > having a default locale of English (UK). The Wikipedia article also sounds like there won't be any use other than in UK ... > >Yes, locale data would be a problem then. Note that in case OOo > >supported scripts, each locale, at least for the language dependent > >parts, would also need Braille locale data then. Quite an amount of new > >locales. > > The "easy" but probably impractical solution would be to setup a default > Locale for each country, that is then modified by the language, and then > by the writing system. Which actually is not that far away from how OOo currently handles it, if you take a look at the locale data of en_* and es_* and *_ZA locales, for example. There is room for improvement, however. A yet more flexible approach would be to have language/script and country definitions and merge them into locales during runtime. > Something that might be pertinent, is that adding these to the > Locale/language options is only half the job. The next step would be to > write a driver to transform the text into something that the respective > printers can accept. But that wouldn't be OOo's job, would it? IMHO that's a system's and printer driver's duty. Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the [EMAIL PROTECTED] account, which I use for mailing lists only and don't read from outside Sun. Thanks. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
