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

[Sayamindu Dasgupta]

On Thu, Sep 11, 2008 at 2:09 AM, Patrik Cevela <patrik.cevela at gmail.com> wrote:
> On Thu, 2008-09-11 at 01:46 +0530, Sayamindu Dasgupta 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
>>
>> Thanks,
>> Sayamindu
>>
>>
>
> And how about distribute language pack over internet in RPM files and
> local distributor will install them into OLPC. In this way of
> distribution will be guaranteed last version of language package. The
> Core system will be same in every OLCP notebook and when someone will
> want to update core, the new version of lang. pack will be downloaded as
> well.
> That will require at least one authorized/skilled partner in country,
> which i don't know if we have.
>
> And how we are keeping OLPC software up to date now?
>

There are customization keys (USB sticks which you put in a laptop to
install stuff - you just boot from it and your stuff get installed)
and a tool called olpc-update (which is in the laptop). From what I
heard a few months back, eventually customization key will be able to
use of RPMs, and I plan  to piggyback on that :-).
Thanks,
Sayamindu




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