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

[Korakurider]

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?

Thanks,
/Korakurider

>
> Thanks,
> Sayamindu
>
>
> --
> Sayamindu Dasgupta
> [http://sayamindu.randomink.org/ramblings]
> _______________________________________________
> Localization mailing list
> Localization at lists.laptop.org
> http://lists.laptop.org/listinfo/localization
>