On 7/23/07, Chusslove Illich wrote: > > [: Simos Xenitellis :] > > The problem would arise if a Mexican wanted to keep the original english > > translation of a word and not use the spanish/spanish one. Are there such > > cases? > > One is from my language. We have sr (which is using Cyrillic script) and > sr@latin (Latin script), and all users know both, but prefer one or the > other. A non-unusual setup is thus sr:sr@latin or sr@latin:sr. In the latter > case, the problem would surface; for example, "Amarok" and "K3b" would be > spelled out same in Latin, but "Амарок" and "К3б" in Cyrillic. Thanks for the example. > > [: Simos Xenitellis :] > > I believe that it captures a small minority of cases. > > Some weighting of pros and cons is always expected, but here we're > considering disk/memory/bandwidth space optimization vs. straight-out broken > behavior. Also, all languages other than non-US English anyway have to live > with that consumption, or even double as much disk space for alphabets > covered by two-byte UTF-8 sequences. Indeed, localisation demands more space than without localisation. My interest is that if we can cut off some of the space without hurting people in the meantime, we should go for it. If we go for it and change gettext/msgfmt, it will be a 10 line patch and no other work will be required. If we decide to make a list of locales that will be happy to be "optimised", we will probably need a more high-level system, and more work to do (such as adding an extra option to msgattrib, --no-copied). This work will have to be carried out either by KDE/GNOME/XFCE/etc, or by the distributions themselves. Simos