Translating distribution specific files ussualy isn't on the top priority list of translation teams. But once the basic user applications are translated (KDE, GNOME, OpenOffice.org, GNU utils,...) one starts to look at ways how to translate their favorite distribution. What is there to translate, how to commit back their work and when will it be available to end users. There is also wish to be able to use existing knowledge and tools so the team can continue with translation while one takes over communication with distribution that is being translated and doesn't have to invest too much time to contribute back translations and other l10n related work. Comparing Debian to other l10n (esp. KDE and GNOME) shows that while there are many status pages that show progress and what is left to do for certain language it lack central point location for contributing translations to Debian. Inside Debian there are number of things that support l10n. In this text I'm going to concentrate on po-debconf templates translations and translations of Debian specific tools (tasksel, apt, ...). There are a few ways to get po catalog template for packages: - download it from l10n status pages [0] - apt-get source if above stats are 404 (it happened to me before, may be an error in service) - download it from CVS or SVN repository - get it from debian-i18n@l.d.o mailing list Locating untranslated or fuzzy translations is also quite simple since we have l10n status pages. Once done translating po message catalog we have to return it back to Debian. There are again a few ways to do this: - post a wishlist bug report against the package - commit it to CVS/SVN repository - mail it to mailing list or to the person maintaining it While the first method seems to be preferred there are many packages that need to be translated and reporting bugs against each and everyone is not something that translator wants to do. Therefor I propose and improvement in this field. The thing I miss in Debian is central point where translation team coordinator can commit translations of his team and get new, fresh ones - without having to deal with BTS for each package template that gets translated in the process. The idea is to open new l10n project on Alioth that would serve as gateway for translators to Debian. Inside CVS/SVN repository there would be directories for packages that would use this service. Each package would have it's directory and inside debian/po and po/ respectively. There are two aspects of this solution: maintainers and translators. Maintainer commits/updates his template to/in repository. Automatic script updates current scripts and optionally announces template change to debian-l10n@l.d.o mailing list. Translators then commit/update their translations. When maintainer decides to upload new version of package all he has to do is run a script that check-outs translations for his package and automatically updates changelog. Advantage of such system is that there is less work for maintainer and translator to update translations. Having central repository also gives possiblity to have write access to translations while not having to be a Debian Developer. It is true that this can be achieved already (and has been with debian-installer) it can't really be done for all the packages that are using CVS/SVN. Giving access to 30+ translators and maintaining the lists and figuring out each project specific instructions is impossible. Most of the tecniques that I described are already used by debian-installer project. Translators have access to SVN repository and they commit new translations. There are automated status reports and string freezes before releases. But having base-config and tasksel in different modules already means that translator has to watch over three repositories. Having centralised repository for translations and team of people taking care of them, working with maintainers and translators using mailing lists and other means of communication would in my opinion greatly improve amount of Debian specific translations of world languages. Debian architecture already allows us to create such project and successfully maintain it - just everything has to be put together and brought to life. -- kind regards Jure Cuhalev gandalf@owca.info
Attachment:
signature.asc
Description: To je digitalno podpisan del =?iso-8859-2?Q?sporo=E8ila?=