[Localization] [PROPOSAL] Change PILGRIM_LOCALES_* to better reflect the current situation

[Korakurider]

On Thu, Sep 11, 2008 at 5:12 PM, Sayamindu Dasgupta <sayamindu at gmail.com> wrote:
> On Thu, Sep 11, 2008 at 11:26 AM, Korakurider <korakurider at gmail.com> wrote:
>> On Thu, Sep 11, 2008 at 5:16 AM, Sayamindu Dasgupta <sayamindu at gmail.com> wrote:
>>> On Thu, Sep 11, 2008 at 12:44 AM, Patrik Cevela <patrik.cevela at gmail.com> wrote:
>>>>
>>>>
>>>> On Wed, 2008-09-10 at 15:09 -0400, C. Scott Ananian wrote:
>>>>> On Wed, Sep 10, 2008 at 2:27 PM, Sayamindu Dasgupta
>>>> <sayamindu at gmail.com> wrote:
>>>>> > On Thu, Aug 28, 2008 at 7:04 PM, Daniel Drake <dsd at laptop.org>
>>>> wrote:
>>>>> >> On Thu, 2008-08-28 at 15:04 +0530, Sayamindu Dasgupta wrote:
>>>>> >>> b) To reflect the current and near future deployments (including
>>>> G1G1
>>>>> >>> 2008) and the level of translations that we have in Pootle, the
>>>>> >>> variables get changed to
>>>>> >>>
>>>> en:es:ar:pl:pt_BR:pt:it:fr:ht:el:mn:mr_IN:th:am_ET:km_KH:ne_NP:ur_PK:rw:ja:de:tr:te:ps:fa_AF:si
>>>>> >>>
>>>>>
>>>>> Can we quantify the space tradeoffs here?  If localization is taking a
>>>>> significant amount of space, it might eventually be reasonable to
>>>>> install translations *only* for the sugar-related packages, and not
>>>>> for bash, sed, etc.  But if they are relatively small, you're right,
>>>>> why not include them all?
>>>>>  --scott
>>>>
>>>> Why we are installing all translations into OLPC? We cannot instal only
>>>> that language support where that notebook is going to be send? We can
>>>> spare lot of disk space.
>>>>
>>>> Patrik
>>>>
>>>
>>> The problem in that case is that we will have to make separate builds
>>> for each and every deployment that is out there, and keep track of
>>> these builds. That would make stuff more difficult.
>>> I have been thinking of better ways to do our language packs, and from
>>> the next release, I will try to come up with an RPM based language
>>> pack system which can be installed without overwriting the existing
>>> translations already in the system. Only the files from the language
>>> pack RPM would be given more precedence while an application looks for
>>> its MO files. This would need a change in the c library that we ship,
>>> but the patch is not big, and it has been used by Ubuntu for quite a
>>> few years, so I think we can get this done for 9.1
>>
>> If you are suggesting changes to gettext runtime...
>>
>> Etoys is using gettext emulation implemented with Smalltalk code.
>> (I think Python do similar)
>> Do you think also changes to Etoys's stuff is needed ?
>> And could you provide pointer to the patch you mentioned?
>>
>
> It's a modification to glibc, so it depends on how gettext is
> emulated. The patch is at
> http://dev.laptop.org/~sayamindu/local-altlocaledir.diff
    Thanks.
    Both Etoys and Python (I reviewed gettext.py) don't use the
function in glibc and decide MO location by themselves, so would need
changes...

    One more question.
    I think SugarLabs intend to deliver artifacts to more non-XO platforms.
    How translations will be delivered for non-XO platform?  Will the
langpack RPM work?
    Or, aren't translations (for langs that aren't blessed by OLPC)
chopped in distro for non-XO?

/Korakurider

> Thanks,
> Sayamindu
>
>
>
> --
> Sayamindu Dasgupta
> [http://sayamindu.randomink.org/ramblings]
>