Hi Osma! > Thanks for your very detailed and enlightening answers!
You're welcome :). > The way I see it, there are a few things that affect the motivation of > translators. > > Goal-related: > A. Fix the translations for myself (or my kids) > B. Fix the translations for all DDL users > C. Fix the translations for all Debian(-derivative) users > D. Fix the translations for all users of the same upstream software > > Process and tool related: > E. As little translation work as possible (i.e. reuse others work)) > F. Easy to get started doing translation work > G. Good tools for doing the translation work > H. Instant gratification (see the results ASAP) Interesting analysis, I must say I've never tried to formalize the human part of our project concerning translations :). This good to have done it! > My motivation was/is mainly A, but BCD are obviously important too. It > would help if there were instructions (and tools) for how to recompile DDL > packages using the latest translations from Transifex. This way, one could > see the results immediately (H) and probably also achieve better quality > translations, as you notice errors better when you see the translated > messages in their actual context of use. I agree. Currently there is no easy way to quickly get Transifex translations into DDL. Translators can ask me to rebuild a DVD, but this may take days depending on my availability. A way to solve this issue could be to write scripts (and then embed them into DDL) able to fetch a given resource on Transifex for a given language, then install it into the running DDL system. Transifex translations are handled by a particular branch of our SVN repository, the branch lang/: http://svn.gna.org/viewcvs/doudoulinux/lang/trunk/ Before a release is officially published, Transifex translations are updated in lang/trunk/apps/ using the script lang/trunk/transifex (a Python library written by the Transifex guys does the low-level job). There is then a script make-l10n.sh in our SVN Debian package branch that builds the packages doudoulinux-l10n-* from these translations: http://svn.gna.org/viewcvs/doudoulinux/packages/trunk/l10n/ It compiles PO files into MO files while also taking care of particular cases, like TS files or non-standard translation processes. This script can probably be used as a good basis to write a script able to update translations on demand in a running DDL. Note that, if it is more complicated than expected, we can also start by just explaining on our website how to update translations for each resource. Another way to allow translators to see their job "live" in DDL, can be to setup an automatic nightly build process of l10n packages. The scripts I use to update translations would be run every night on a server. The output packages would be placed in a specific developers repository that would just need to be declared in DDL. Of course this wouldn't be as immediate as the first solution, translators would have to wait for the next day to see their changes for real. > I can understand this, DDL being a volunteer effort etc. It's not a > problem as long as new translators become available (like myself - but no > promises on long term availability!) and it's easy to get started (F). I > was pleased to be accepted into the Finnish team within an hour or two of > putting in my request to join, but it would have been frustrating to have > to wait a week or more just to be able to start typing in messages in > Transifex. We usually try to accept people in a day, but it may happen that we are not available. Language team managers can also accept new contributors but it seems not many of them take this role. This is maybe not clear enough for them whether they can really manage their translation team or not. The more we delegate, the best! > > Also we are currently working on version 2.5, a migration of DDL from > > Debian Squeeze to Debian Wheezy. The purpose of 2.5 is to prepare 3.0, > > which will bring updated translations from Transifex (for Debian Wheezy) > > ? and probably larger changes in the software selection. Version 2.5 > > will be kind of ?vanilla? release concerning translations. > > This sounds promising. But what do you mean by vanilla translations? > > 1. Squeeze packages with current Transifex translations (2.1 status quo) > 2. Squeeze packages with Wheezy-updated Transifex translations > 3. Wheezy packages with current Transifex translations > 4. Wheezy packages with Wheezy translations (no Transifex) > 5. Wheezy packages with Wheezy-updated Transifex translations 4 or 5, if updates of Wheezy can bring new translations (I fear it is never the case though). > I think one major obstacle is that since DDL uses stable Debian versions > (or even oldstable), and Debian stable releases tend to be several > releases/years behind upstream packages, there is likely a big version gap > between what DDL uses and where upstream development is focused. Yes, we're late compared to the Debian development cycle, since the beginning of our project indeed… I want to make up the delay and be in phase with Debian, but this is a hard job, harder than expected. Version 2.x required a long development period to bring a new, better interface. Version 3.x is hindered by the incompatibility of GDM3 vs. GDM2. Ideally we should already be working on Debian testing. We will in the future, but I can't tell when! > It could be argued that real development (including translation work) > would best be done in the upstream projects, not in distributions like > Debian or derivatives like DDL. This way everyone using the software would > eventually benefit. But if your end goal is something like A, it's not > very motivating to work with upstream and have to wait several years for > the changes to trickle down first to Debian and then to DDL. It seems people are more encline to start improving translations applications for DoudouLinux than for upstream projects directly. This is quite logical since they clearly see the benefit: their children! Also the problem with upstream projects is that they're using independent repositories and processes. Transifex solves this by providing a unique user account and a single access point. Ideally, if all the projects were sharing the same translation infrastructure, Transifex or another one, life could be easier for everyone. The only missing feature in Transifex is the ability to share a resource between projects, which would allow us to just symlink to upstream translation projects instead of duplicating their messages. > I won't promise anything yet, but it'd be nice to get access to the > tools/scripts you used for syncing. I'm somewhat familiar with i18n tools, > having used gettext etc. in some of my own projects. Take a look at lang/trunk/ on SVN. The script fetch-pofiles is supposed to fetch and merge PO files from upstream, provided you give the URL in a per-resource configuration file. I remember to have found it not so satisfying, I don't remember exactly why. Maybe the merging operation was more tricky than imagined. -- Cheers, JM.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Doudoulinux-lang mailing list [email protected] https://mail.gna.org/listinfo/doudoulinux-lang
