[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Separating the process of translation and packaging



Hello,
I have been looking at possible ways to decouple the translation
workflow from the packaging workflow - eg, if we want, we could
install updated translations for a language later on. The usage
scenarios for such a requirement are as follows:

Scenario 1:
At OLPC, we have few releases per year, but new deployments and pilot
projects keep happening throughout the year. Normally, translation
activity for a given language pick up only after the relevant
deployment or the pilot project is announced - it is typically seen as
a part of the logistics leading to a deployment/pilot (especially true
for non-European languages). In such a situation, we (OLPC) would
really like to see the process of translation and packaging becoming
independent of each other. Updating translation in the relevant
packages, and then redeploying the packages is not an option for us,
due to the limited time-slot that is available between translations
getting completed by on-site people and the roll-out day.

Scenario 2:
We want translations to be user modifiable (and user share-able).
There has been talk about a sugar activity to let users enhance and
modify translations, and one of the former OLPC engineers, C Scott
Ananian had proposed a more interesting "click to translate" approach
(http://cscott.net/Publications/OLPC/fudcon-i18n.pdf) in last year's
Sugar Camp.

I have looked at various ways to make this happen, and the best
possible solution looks like what Ubuntu does for its language pack
system. They have patched glibc and Python so that mo files are looked
up in /usr/share/langpack-locale (after the look up has been done in
/usr/share/locale). I think this can be extended so that the alternate
translation directory can be specified via a configuration file
(similar to /etc/ld.so.conf). Would this be an acceptable approach for
Fedora ?

I have looked up various other methods that are currently practised -
but they seem project specific (KDE, OpenOffice.org and Firefox), and
I don't think any of them would support straightforward installation
of translations in $HOME (a requirement for Scenario 2). Is there any
better way to do this ? (I'm not very familiar with the internals of
RPM or Yum, so I did not explore doing this by the packaging system
much)

Thanks,
Sayamindu


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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]