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

[Sayamindu Dasgupta]

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,
Sayamindu



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