[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: MO files not optimised enough (esp. en_GB, en_CA, etc) in KDE
From:       "Simos Xenitellis" <simos.lists () googlemail ! com>
Date:       2007-07-23 20:05:00
Message-ID: 598e9210707231305l737d3b3cgbffa7706c69646ce () mail ! gmail ! com
[Download RAW message or body]

On 7/23/07, Chusslove Illich <caslav.ilic@gmx.net> 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

[prev in list] [next in list] [prev in thread] [next in thread]