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

[Sayamindu Dasgupta]

On Thu, Sep 11, 2008 at 2:15 PM, Korakurider <korakurider at gmail.com> wrote:
> 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...
>


Ok - I'll take a look. Ubuntu does this for Python based programmes as
well, so I'll take a look at their Python package.

>    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?
>

There might be two options
a) Keep the existing language pack option for distributions that do
not carry this glibc/python patch
b) Ask the distributions to patch their own glibc and try to utilize
the RPM based packs (we can use alien to convert the RPMs into debs if
required - these should not be much complicated RPMs)

Thanks,
Sayamindu


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