Tim,
while I see the automatic commits to tde-i18n I was thrilled! Update 'po' files was prerequisite to enable the translation of new texts and thanks to your great work this is now possible!
Thank you very much!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
Tim,
while I see the automatic commits to tde-i18n I was thrilled! Update 'po' files was prerequisite to enable the translation of new texts and thanks to your great work this is now possible!
Thank you very much!
-- Slávek
No problem! I finally had a chunk of time to work on TDE and was able to figure out the translation system enough to get this working. This should resolve the majority of the translation-related bugs; translators can now pull, translate with KBabel or similar, and commit directly back to tde-i18n as needed.
It is interesting to see how much infrastructure is required to properly manage TDE--this project isn't something you just throw up on a barebones web server and leave alone. ;-)
Tim
No problem! I finally had a chunk of time to work on TDE and was able to figure out the translation system enough to get this working. This should resolve the majority of the translation-related bugs; translators can now pull, translate with KBabel or similar, and commit directly back to tde-i18n as needed.
I was also thrilled by seeing the same commit. Tim, could you explain briefly how .pot files are created (which sequence of commands are executed)? I think we need to add some kind of instructions on our wiki about the translation process, so that users can actually work on that actively.
Also, what is the frequency of automatic generation? If it is too frequent (say daily) this may cause a problem when applying patches provided by users, because by the time we get to apply the patch, the generation date included in each file may have change due to the next automatic update. This would require manual intervention on each modified file to apply the patch. I think a good frequency would be something like once a month. What do you think?
Cheers Michele
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@yahoo.it wrote:
No problem! I finally had a chunk of time to work on TDE and was able to figure out the translation system enough to get this working. This
should
resolve the majority of the translation-related bugs; translators can now pull, translate with KBabel or similar, and commit directly back to
tde-i18n as needed.
I was also thrilled by seeing the same commit. Tim, could you explain briefly how .pot files are created (which sequence of commands are executed)? I think we need to add some kind of instructions on our wiki about the translation process, so that users can actually work on that actively.
Also, what is the frequency of automatic generation? If it is too frequent (say daily) this may cause a problem when applying patches provided by users, because by the time we get to apply the patch, the generation date included in each file may have change due to the next automatic update. This would require manual intervention on each modified file to apply the patch. I think a good frequency would be something like once a month. What do you think?
Cheers Michele
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
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 think it depends on the process. If a user can push the updated translation files directly to GIT, then no problem with daily updates. Instead if the user has to submit a patch and then one of the developers have to push it, then daily updates are not the best IMO.
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.
Yes, fully agree on this.
Cheers Michele
If a user can push the updated translation files directly to GIT, then no
problem with daily updates.
Instead if the user has to submit a patch and then one of the developers
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@yahoo.it wrote:
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 think it depends on the process. If a user can push the updated translation files directly to GIT, then no problem with daily updates. Instead if the user has to submit a patch and then one of the developers have to push it, then daily updates are not the best IMO.
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. Yes, fully agree on this.
Cheers Michele
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
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.
Ah ah! I was replying to this comment when I suddenly realized that my original thinking was at fault. The translated .po files do not need to be *patched* to GIT, they can just be *copied* over the older copies when new versions are submitted. This does not require any "manual patching work" and can be achieved quite quickly even by few developers. In this view, daily updates would work fine.
Given the development rate, I still think that daily updates (or even weekly) would be overkill, since most of the time only the date of generation would change and nothing else. Probably by-weekly or monthly is a good choice.
Cheers Michele
Le 02/10/2014 09:32, Michele Calgaro a écrit :
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.
Ah ah! I was replying to this comment when I suddenly realized that my original thinking was at fault. The translated .po files do not need to be *patched* to GIT, they can just be *copied* over the older copies when new versions are submitted. This does not require any "manual patching work" and can be achieved quite quickly even by few developers. In this view, daily updates would work fine.
Given the development rate, I still think that daily updates (or even weekly) would be overkill, since most of the time only the date of generation would change and nothing else. Probably by-weekly or monthly is a good choice.
Cheers Michele
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
On 2014/10/04 07:21 PM, François Andriot wrote:
Le 02/10/2014 09:32, Michele Calgaro a écrit :
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.
Ah ah! I was replying to this comment when I suddenly realized that my original thinking was at fault. The translated .po files do not need to be *patched* to GIT, they can just be *copied* over the older copies when new versions are submitted. This does not require any "manual patching work" and can be achieved quite quickly even by few developers. In this view, daily updates would work fine.
Given the development rate, I still think that daily updates (or even weekly) would be overkill, since most of the time only the date of generation would change and nothing else. Probably by-weekly or monthly is a good choice.
Cheers Michele
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
Francois, I see you already experienced the problem I was initially worried with. IMO we should proceed as follow: 1) only .pot files should be automatically generated, not .po. 2) new .po files should be copied over existing ones when available. We need some kind of infrastructure to allow users to download updated .pot files and upload updated .po files. Whatever solution we find, Tim needs to approve it and put it in place. Perhaps an appropriate page on the TDE website could do the job.
For the fuzzy translation I can't say much, since I haven't used KBabel yet. How is a fuzzy translation generated exactly?
Cheers Michele
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
Le 02/10/2014 09:32, Michele Calgaro a écrit :
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.
Ah ah! I was replying to this comment when I suddenly realized that my original thinking was at fault. The translated .po files do not need to be *patched* to GIT, they can just be *copied* over the older copies when new versions are submitted. This does not require any "manual patching work" and can be achieved quite quickly even by few developers. In this view, daily updates would work fine.
Given the development rate, I still think that daily updates (or even weekly) would be overkill, since most of the time only the date of generation would change and nothing else. Probably by-weekly or monthly is a good choice.
Cheers Michele
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
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
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.
That is what I would do (as I have suggested a few times already).
On 5 October 2014 04:35, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
Le 02/10/2014 09:32, Michele Calgaro a écrit :
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.
Ah ah! I was replying to this comment when I suddenly realized that my original thinking was at fault. The translated .po files do not need to be *patched* to GIT, they can just be *copied* over the older copies when new versions are submitted. This does not require any "manual patching work" and can be achieved quite quickly even by few developers. In this view, daily updates would work fine.
Given the development rate, I still think that daily updates (or even weekly) would be overkill, since most of the time only the date of generation would change and nothing else. Probably by-weekly or monthly is a good choice.
Cheers Michele
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
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 SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)
iFYEARELAAYFAlQwL9gACgkQLaxZSoRZrGGHzwDgrzo4OgfboCYQSj0CSa17mhr0 vhYvruhk1khx4wDggCPOYxPP1Ri95radA+LGO4bqHkGJGw79LpnGFQ== =CiIg -----END PGP SIGNATURE-----
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
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.
That is what I would do (as I have suggested a few times already).
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
Ok Tim, here is my suggestion. Take a look at Transifex. MATE, XFCE, Pidgin, XMBC and thousands of other projects use it. It simplifies the work of the translator (and translation team) so much. You upload the .pot, create the language teams, the translator can download it for offline translation and upload it when it's done. They can translate it online as well and you can see the stats and get the translated .po files and merge them into your source whenever you want to.
Once the language team is created the team leader looks after the running of the team.
On 5 October 2014 09:16, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
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.
That is what I would do (as I have suggested a few times already).
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 SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)
iFYEARELAAYFAlQwcdoACgkQLaxZSoRZrGEESwDdEU5pOYIoSVRe9C5jxKtpjkSQ ljAw+7Y0qEKx8wDeLDG/2LIWE3xSYy/UKoEdi5ddulM/NavHz0X9mw== =ZfRv -----END PGP SIGNATURE-----
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
Ok Tim, here is my suggestion. Take a look at Transifex. MATE, XFCE, Pidgin, XMBC and thousands of other projects use it. It simplifies the work of the translator (and translation team) so much. You upload the .pot, create the language teams, the translator can download it for offline translation and upload it when it's done. They can translate it online as well and you can see the stats and get the translated .po files and merge them into your source whenever you want to.
Once the language team is created the team leader looks after the running of the team.
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
-
François Andriot -
Michael . -
Michele Calgaro -
Slávek Banko -
Timothy Pearson