Re: Moduleset Reorganization vs. L10N
El dt 12 de 10 de 2010 a les 16:03 +0200, en/na Vincent Untz va escriure: Le mardi 12 octobre 2010, à 12:10 +0200, Claude Paroz a écrit : b) we enforce a GNOME stats/translation tool, and we make the necessary steps so as it supports distributed development. For example, that could mean that the tool on l10n.gnome.org hosts an i18n version of each tracked branch where translations are committed by GNOME teams, and the modules have to merge regularly this branch into main repositories (at least before each release). ++ single location for translators - enforcing a special workflow for maintainers - risk that maintainers omit to merge i18n branch My preference is for b) as it is easier for translators: only one workflow has to be handled. b) sounds good, indeed. Note that you can make it easy for maintainers if we provide some Makefile rules that they can use to update the translations during make dist. (That's also what transifex wants to do in the future) Vincent It wouldn't be easier(?) if the non-hosted git.gnome.org applications have a git clone version on git.gnome.org which is cron-updated? Then l10n.gnome.org should make commits in the git.gnome.org version and the maintainer should only had to pick the translations from there. Cheers, -- gil forcada [ca] guifi.net - una xarxa lliure que no para de créixer [en] guifi.net - a non-stopping free network bloc: http://gil.badall.net planet: http://planet.guifi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization vs. L10N
2010-10-12 17:41 keltezéssel, Gil Forcada írta: Then l10n.gnome.org should make commits in the git.gnome.org version and the maintainer should only had to pick the translations from there. No, please do not want to rely on then the maintaner will commit the files/merge the branch. He won't, sorry. This is of course the worst case scenario, but we should be prepared for that. For example, we already have two external deps for which the translation process relies on the maintainer committing po files from Bugzilla. Of these two, one maintainer commits such translations, the other(s) do not[1]. Another similar example is GNU TP, where pot files are updated when the maintainer pushes them, and translations are also committed by the maintainer. These events may or may not happen, consequence is that GStreamer stats are out of sync between TP and Damned-lies[2]. This shows to me that expecting the maintainer to push our translations is not a reliable process (it involves busy humans, yay!), so we should try to search for solutions where the only human involved in pushing translations to the repository is the L10N team's committer. Regards Gabor Kelemen [1]: https://bugs.webkit.org/buglist.cgi?query_format=specificorder=relevance+descbug_status=__open__product=WebKitcontent=translation - no finger pointing really, just an illustration. [2]: Compare http://l10n.gnome.org/languages/hu/freedesktop-org/ui/ and http://translationproject.org/team/hu.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization vs. L10N
2010/10/12 Gabor Kelemen kelem...@gnome.hu: 2010-10-12 17:41 keltezéssel, Gil Forcada írta: Then l10n.gnome.org should make commits in the git.gnome.org version and the maintainer should only had to pick the translations from there. No, please do not want to rely on then the maintaner will commit the files/merge the branch. He won't, sorry. This is of course the worst case scenario, but we should be prepared for that. For example, we already have two external deps for which the translation process relies on the maintainer committing po files from Bugzilla. Of these two, one maintainer commits such translations, the other(s) do not[1]. Another similar example is GNU TP, where pot files are updated when the maintainer pushes them, and translations are also committed by the maintainer. These events may or may not happen, consequence is that GStreamer stats are out of sync between TP and Damned-lies[2]. This shows to me that expecting the maintainer to push our translations is not a reliable process (it involves busy humans, yay!), so we should try to search for solutions where the only human involved in pushing translations to the repository is the L10N team's committer. Yes it would be best to do the syncing back and forth without human intervention. But as someone already mentioned it should be possible to set it up automatically with some clever cron jobs. \Kenneth ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization vs. L10N
2010/10/12 Claude Paroz cla...@2xlibre.net: Sorry, I was away for some days and wasn't able to give my opinion sooner. First of all, I'd like to support that using the GNOME infrastructure is invaluable for translators. It is not rare for us to commit in modules, (POTFILES.in, translator comments, other i18n fixes...) and having only one bugzilla to cope with is also very nice. We should continue to encourage developers to use it, but I wonder how we could do this concretely... Returning to basics, I think that to be a GNOME-blessed module at i18n level, the criteria should be that the module is translated through established GNOME translation teams, regardless the tool used. It's not that GNOME teams are the best one, but as others have recently reminded us, it's a matter of consistency and QA. I hope that the release team support this view. Another important point for me is that for any module, only one translation workflow is chosen. That means that different modules might choose different workflows, even if I consider this suboptimal at a team-management level. I can elaborate on this if needed. Now that leaves us with essentially two ways forward: a) each module can choose its preferred tool/workflow and the module owner has to assure that 'commit-like' access is reserved to GNOME teams coordinators. A variant of this would be that a subset of tools are blessed by the GTP, to prevent tool proliferation, which would become unmanageable by coordinators. + free choice for maintainers + does not require any change to current translation tools - duplicated team management - multiple workflows to be familiar with - hard to detect string freezes b) we enforce a GNOME stats/translation tool, and we make the necessary steps so as it supports distributed development. For example, that could mean that the tool on l10n.gnome.org hosts an i18n version of each tracked branch where translations are committed by GNOME teams, and the modules have to merge regularly this branch into main repositories (at least before each release). ++ single location for translators - enforcing a special workflow for maintainers - risk that maintainers omit to merge i18n branch My preference is for b) as it is easier for translators: only one workflow has to be handled. Mine too. If we can get developers to agree and we can agree that it is a fair demand then that is definitely the way we want to go. IMHO, the question about the GNOME main translation stats tool (Damned-Lies or Transifex or whatnot) is secondary, and should be addressed after we've defined where we want to go. Agreed. \Kenneth ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization vs. L10N
Le mardi 12 octobre 2010, à 12:10 +0200, Claude Paroz a écrit : b) we enforce a GNOME stats/translation tool, and we make the necessary steps so as it supports distributed development. For example, that could mean that the tool on l10n.gnome.org hosts an i18n version of each tracked branch where translations are committed by GNOME teams, and the modules have to merge regularly this branch into main repositories (at least before each release). ++ single location for translators - enforcing a special workflow for maintainers - risk that maintainers omit to merge i18n branch My preference is for b) as it is easier for translators: only one workflow has to be handled. b) sounds good, indeed. Note that you can make it easy for maintainers if we provide some Makefile rules that they can use to update the translations during make dist. (That's also what transifex wants to do in the future) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization vs. L10N
ti., 12.10.2010 kl. 16.03 +0200, skrev Vincent Untz: Le mardi 12 octobre 2010, à 12:10 +0200, Claude Paroz a écrit : b) we enforce a GNOME stats/translation tool, and we make the necessary steps so as it supports distributed development. For example, that could mean that the tool on l10n.gnome.org hosts an i18n version of each tracked branch where translations are committed by GNOME teams, and the modules have to merge regularly this branch into main repositories (at least before each release). ++ single location for translators - enforcing a special workflow for maintainers - risk that maintainers omit to merge i18n branch My preference is for b) as it is easier for translators: only one workflow has to be handled. b) sounds good, indeed. Note that you can make it easy for maintainers if we provide some Makefile rules that they can use to update the translations during make dist. But it should also be easy for testers to compile the package with updated translations without having to do make dist I guess. Perhaps documenting how to add an updated translation by just copying the file with the right name into the po/ dir is good enough? Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
