glibc does not currently have a locale file for Tibetan. This makes it hard to run programs in the native language. This bug is to track the addition of the locale. Is there a process for getting a new locale added upstream?
http://sources.redhat.com/bugzilla/show_bug.cgi?id=368 for dz_BT (Bhutanese) which is a close language to Tibetan may be a good reference.
A bugreport like this is useless without the actual patch to add the locale. Only over that we can discuss if it can be added and who will be the maintainer of that locale.
Chris, would you be able to assist with the Tibetan locale? I am still waiting to hear from Ngodrup...
Hi Jens I'd be happy to *assist* with this. A Tibetan (bo) locale would pretty much the same as a Dzongkgka (dz) locale. One important difference is that localised nmes for days of the week should be shifted back by one. The names (and abbreviations) for the days of the week are the same words in Tibetan & Dzongkha - but in Dzongkha they are one day ahead - e.g. གཟའ་ཉི་མ་ [ \u0F42\u0F5F\u0F60\u0F0B\u0F49\u0F72\u0F0B\u0F58\u0F0B ] is the Dzongkha name for Saturday but the Tibetan name for Sunday. Tibetan collation is a true sub-set of Dzongkha collation - so LC_COLLATE element from dz_BT locale should work fine for Tibetan locale. Country specific things like currency, time zone, etc could be taken zh_CN for a bo_CN locale; and from hi_IN or en_IN for a bo_IN locale. There is now also considerable locale information for Tibetan in CLDR <http://unicode.org/cldr/apps/survey?s=fdL03y20m_ux19FZiVdzDSAfSEg,&_=bo> Probably the easiest thing to do is take the dz_BT locale and make changes wherever there is a difference for Tibetan. - Chris - Chris
One other thought.. In China there is apparently a localised version of Red Flag Linux including Tibetan. It must have a bo_CN locale. The data in that would be official since that project was supported by the Govt. of China and Tibet University in Lhasa. That distribution may use the Chinese GB 18030 based encoding for pre-composed Tibetan rather than Unicode - but it is easy enough to convert from that character encoding to Unicode. I also don't know where to find the CVS or SVN for Red Flag Linux - and if everything is in Chinese as I suspect it might be it would be difficult for me to locate the relevant file since I don't read Chinese.
I've added bo_CN and bo_IN locales upstream. I know nothing about the language so somebody will have to check the files.
Thanks, Uli, that is great news. Chris, could you try to review: http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/libc/localedata/locales/bo_CN?content-type=text/plain&cvsroot=glibc http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/libc/localedata/locales/bo_IN?content-type=text/plain&cvsroot=glibc
Will try to do this weekend - I'll first need to convert all the "<U0Fnn>" to Unicode to make it humanly readable. - Chris.
(In reply to comment #8) > Will try to do this weekend - I'll first need to convert all the "<U0Fnn>" to > Unicode to make it humanly readable. In the glibc sources there is a program called show-ucs-data.
Thanks for all the help on this. :) Changing to MODIFIED since glibc-2.7.90 in rawhide (Fedora devel) now contains the locale. Would still greatly appreciate it if you have time to review them, Chris.
Based on the date this bug was created, it appears to have been reported during the development of Fedora 8. In order to refocus our efforts as a project we are changing the version of this bug to '8'. If this bug still exists in rawhide, please change the version back to rawhide. (If you're unable to change the bug's version, add a comment to the bug and someone will change it for you.) Thanks for your help and we apologize for the interruption. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
I see /usr/share/locale/{bo_CN,bi_IN} in current pre-F9. I guess eventually it would be nice to have translations too. Chris, do you know anyone in the community who might be willing to contribute them?