In the various translation projects I am a member of I have see updates each week and at times each day depending on the package and how much work is being done to it. I would, personally, like to be able to work on translation and have some page that gives instructions on what is required. Things like where to go, what packages are high priority, how to submit the translation, how to review the translations done by others etc etc etc. are all helpful to novice translators and also to individuals who have never used the site the translations are based at. On 2 October 2014 12:40, Michele Calgaro <michele.calgaro(a)yahoo.it> wrote:

problem with daily updates. have to push it, then daily updates are not the best IMO. Most translators don't know about GIT, and if I may voice my opinion nor should they have to. Sites like Transifex exist for good reason. Translators can work on multiple projects within the one site and one login. While I'm not a fan of Canonical (although I used be be a big fan of Ubuntu) I do like Launchpad but I much prefer sites like Transifex. People who have been on sites such as this look for new projects, they have their resources (glossaries etc.) and this can make translation quick and relatively painless (as long as the source pot files are consistent with terminology and conventions). Users don't submit patches they translate the original pot file, which btw remains intact, and a po file is created. Everytime an updated pot file is uploaded the site lets the user know how many strings/words and what % of the file requires translating. Everytime the translator translates a string the po file is updated. All that is then required is reviewing the translation and that is done within each language team leaving the developer to continue developing. That brings me to the 2nd part of my reply. Sites like transifex have 99% of the details already there, translators don't have to wade through alot of information, developers don't have to write up alot of information, it is already 99% there. All the developer really needs to do is load the pot files in the order they require them to be translated, and start off the different translation teams (language teams). Once a team has a team leader the team leader can control the team members leaving the developer with simply uploading the pot files and downloading the translated po files in a timely manner (once a week /month or so) and merging them into the source packages as they would do anyway. Cheers. On 2 October 2014 15:31, Michele Calgaro <michele.calgaro(a)yahoo.it> wrote:

Le 02/10/2014 09:32, Michele Calgaro a écrit : I've already had a problem using translation patches today. I used kbabel yesterday to update missing/fuzzy translations in french tde-i18n. Then I created a big patch file that I intended to submit today. But today, the tde-i18n package has been updated in GIT, and my patch no longer applies correctly. I've seen 2 main causes: - The header of ".po" file contains a "build date" that can change at every update - a single new "msgid/msgstr" in a large list can cause a big chunk of patch file to fail So I agree, we should not proceed using patches for translation files. Then, how can we do ? Do we open a bug report to collect all ".po" files ? Still, I wonder, if I update the .po files that I've downloaded today, then I submit them tommorrow... if the git tde-i18n is automatically updated during that time, will pushing my file to Git cause a loss of the automatic updates ? Also, since the automatic .po files update is in place, there are MANY fuzzy translations for the new strings. This can cause lots of misunderstanding for people using tde-i18n ! Having bad translations is even worse than no translation at all, IMO. Now if every language has got lots of fuzzy translations as french language did, we need to fix this ASAP. It is important that non-developper can help us ! François

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224 I can shut the automated update back down for now until a solution can be formalized if that would help. The automated update does not change the dates unless something else has changed, however as you can see what usually changes are the source line numbers and nothing else. I suspect strongly that the translation team is going to have to use the msgmerge utility when submitting new translations instead of the standard GIT tools. I'm starting to wonder if instead of allowing direct GIT access to the i18n tree we may need to have a service acting as middleman, accepting modified .po files and merging them into the tree. This is a happy problem; TDE development is happening at a much faster rate and therefore we need to figure out how to let that continue while the translation team works. :-) Finally, should we have a separate i18n mailing list? I can set one up real fast if desired. Tim

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224 I haven't seen the suggestions, sorry. Been busy with fixing bugs. I will need to do some research on the best way to implement this. The absolute best would be some kind of GIT pre-commit hook that rewrites the commit with msgmerge, but I don't know if that's even possible. If not, I know QuickBuild has some kind of multi-user translation manager that might be able to be used. I've disabled the i18n updater until we can figure this out. I can always give it a manual run before R14 release. Tim

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224 We have the ability to do something very similar with QuickBuild, except that QuickBuild is rebranded Launchpad and therefore AGPL-licensed. There are tens of thousands of .po files in that tde-i18n repository; whatever we use *must* fully support automated upload and download. In any case, if this type of Web-based system is the route the translators would like to take (and I do want to leave it up to them as much as possible), there will need to be some significant restructuring in the i18n repository. I don't think we can reasonably do this for R14, so this becomes a post-R14 goal. For now, as mentioned, the automated updater is offline so please use msgmerge manually and fix up the translations as much as possible. I'll run the updater once again before release to update line numbers and such. Tim