Problems with Vietnamese translation
I have just done a 'clean' configure and make install from the currend subversion trunk. I see the following issues:
There is a templates/vi directory in the trunk. It is empty, but it really shouldn't be there at all.
More importantly, po2templ.py didn't create any templates in templates/vi. This appears to be because in messages/vi/LC_MESSAGES/mailman.po, the magic
#: templates/en/filename:1
headers are missing the ' ' between '#:' and 'templates'.
On 25/04/2006, at 4:38 AM, Mark Sapiro wrote:
I have just done a 'clean' configure and make install from the currend subversion trunk. I see the following issues:
There is a templates/vi directory in the trunk. It is empty, but it really shouldn't be there at all.
Sorry, while implementing my initial translation, I created the translation paths in both the current branch and in trunk, not realizing that the templates/xx directory is no longer necessary in / trunk. I only caught onto that while updating the trunk mailman.po file, and forgot to go back and remove that directory. I'll do that now (before I forget again ;) ).
More importantly, po2templ.py didn't create any templates in templates/vi. This appears to be because in messages/vi/LC_MESSAGES/mailman.po, the magic
#: templates/en/filename:1
headers are missing the ' ' between '#:' and 'templates'.
AFAIK, there shouldn't be any templates in trunk. They've been converted into the mailman.po file. This will be much easier to manage, especially when updating translations.
from Clytie (vi-VN, Vietnamese free-software translation team / nhóm Việt hóa phần mềm tự do) http://groups-beta.google.com/group/vi-VN
Clytie Siddall wrote:
On 25/04/2006, at 4:38 AM, Mark Sapiro wrote:
More importantly, po2templ.py didn't create any templates in templates/vi. This appears to be because in messages/vi/LC_MESSAGES/mailman.po, the magic
#: templates/en/filename:1
headers are missing the ' ' between '#:' and 'templates'.
AFAIK, there shouldn't be any templates in trunk. They've been =20 converted into the mailman.po file. This will be much easier to =20 manage, especially when updating translations.
Yes, there shouldn't be any templates in the subversion trunk, but that isn't what I was saying. I'm saying that 'make install' did not extract the templates from the mailman.po for the templates/vi/ directory in the insatlled system. The reason for this is the magic templates headers in messages/vi/LC_MESSAGES/mailman.po look like
#:templates/en/admindbdetails.html:1 #:templates/en/admindbpreamble.html:1 #:templates/en/admindbsummary.html:1 #:templates/en/adminsubscribeack.txt:1 #:templates/en/adminunsubscribeack.txt:1 etc.
and they should look like
#: templates/en/admindbdetails.html:1 #: templates/en/admindbpreamble.html:1 #: templates/en/admindbsummary.html:1 #: templates/en/adminsubscribeack.txt:1 #: templates/en/adminunsubscribeack.txt:1 etc.
because the po2templ.py script that extracts them from the mailman.po file is looking specifically for
if line.startswith('#: templates'):
Thanks for following this up, Mark. :)
On 25/04/2006, at 2:58 PM, Mark Sapiro wrote:
AFAIK, there shouldn't be any templates in trunk. They've been =20 converted into the mailman.po file. This will be much easier to =20 manage, especially when updating translations.
Yes, there shouldn't be any templates in the subversion trunk, but that isn't what I was saying. I'm saying that 'make install' did not extract the templates from the mailman.po for the templates/vi/ directory in the insatlled system. The reason for this is the magic templates headers in messages/vi/LC_MESSAGES/mailman.po look like
#:templates/en/admindbdetails.html:1 #:templates/en/admindbpreamble.html:1 #:templates/en/admindbsummary.html:1 #:templates/en/adminsubscribeack.txt:1 #:templates/en/adminunsubscribeack.txt:1 etc.
and they should look like
#: templates/en/admindbdetails.html:1 #: templates/en/admindbpreamble.html:1 #: templates/en/admindbsummary.html:1 #: templates/en/adminsubscribeack.txt:1 #: templates/en/adminunsubscribeack.txt:1 etc.
because the po2templ.py script that extracts them from the mailman.po file is looking specifically for
if line.startswith('#: templates'):
Weird. I used the latest .pot for Mailman, so the headers _should_ be correct. I can't see how msgmerge can have changed that: it only matches translations to original text. If the templates need to be there in the installed system, I'll have to fix this. <sigh> But I'd still like to know how it happened. :(
Your next mail:
There is no entry for Vietnamese in the add_languages() statements in Defaults.py.in in the Release_2_1-maint branch or in the LANGUAGE_DICT entries in Defaults.py.in in the trunk.
Who should add such entries? Should I? If so, please tell me what I should do.
Is this analagous with adding a language code to the ALL_LINGUAS line in configure.in or configure.ac ?
from Clytie (vi-VN, Vietnamese free-software translation team / nhóm Việt hóa phần mềm tự do) http://groups-beta.google.com/group/vi-VN
Clytie Siddall wrote:
Weird. I used the latest .pot for Mailman, so the headers _should_ be correct. I can't see how msgmerge can have changed that: it only matches translations to original text. If the templates need to be there in the installed system, I'll have to fix this. <sigh> But I'd still like to know how it happened. :(
I don't know. The mailman.pot does have the spaces between '#:' and the path. msgmerge on my Cygwin test installation actually will put the space in between '#:' and the path even if it isn't there in the original mailman.po file, but if there are different msmerges out there that exhibit different behavior, perhaps bin/po2templ.py needs to be updated to account for differing formats.
In my case, I think the problem could be addressed by reordering messages/Makefile.in to run msgmerge on the mailman.po before po2templ.py and installing the templates, but if there are different msgmerge behaviors, that wouldn't work for everyone. We'd need to update po2templ.py.
It shouldn't be difficult to work up a patch to po2templ.py (using re) that would make it more robust in this area. I'm willing to do that, but I may not have time to get to it for a few days.
Your next mail:
There is no entry for Vietnamese in the add_languages() statements in Defaults.py.in in the Release_2_1-maint branch or in the LANGUAGE_DICT entries in Defaults.py.in in the trunk.
Who should add such entries? Should I? If so, please tell me what I should do.
The comments in Defaults.py.in say in part
# Vgg: Language descriptions and charsets dictionary, any new supported # language must have a corresponding entry here.
I think this means it's up to the translator to put it there, but I'm not really familiar with Mailman i18n procedures.
If you look at Defaults.py.in in the trunk and in the Release_2_1-maint branch (they're different in this respect) at the very end of the file, it should be obvious what to do.
Is this analagous with adding a language code to the ALL_LINGUAS line in configure.in or configure.ac ?
No, not really.
configure.in contains commands to build ALL_LINGUAS by listing the messages directory and selecting all subdirectory names of form '..' and '.._..'.
The entries in Defaults.py are the same language codes, but they contain the 'name' of the language (e.g., _(Vietnamese)), and the name of the character set for the language.
Mark Sapiro wrote:
It shouldn't be difficult to work up a patch to po2templ.py (using re) that would make it more robust in this area. I'm willing to do that, but I may not have time to get to it for a few days.
Here's a patch
--- MM-Trunk/mailman/bin/po2templ.py 2006-04-18 18:06:32.484375000 -0700 +++ test-mailman-trunk/bin/po2templ.py 2006-04-26 19:42:24.843750000 -0700 @@ -27,8 +27,11 @@ Usage: po2templ.py languages """
+import re import sys
+cre = re.compile('^#:[ ]*templates/en/(?P<filename>.*):1') +
? def do_lang(lang): @@ -38,10 +41,11 @@ fp = file('messages/%s/LC_MESSAGES/mailman.po' % lang) try: for line in fp: - if line.startswith('#: templates'): + m = re.search(cre, line) + if m: in_template = True in_msg = False - filename = line[16:-3] + filename = m.group('filename') outfilename = 'templates/%s/%s' % (lang, filename) continue if in_template and line.startswith('#,'):
I tested this and it seems to work fine whether or not mailman.po has a space after the '#:'.
Tokio,
Do you think we should go ahead and commit this on the trunk?
Hi Mark,
I tested this and it seems to work fine whether or not mailman.po has a space after the '#:'.
Tokio,
Do you think we should go ahead and commit this on the trunk?
Thanks for this patch. I've committed this on the trunk slightly differently, though.
Cheers,
On 27/04/2006, at 12:46 AM, Mark Sapiro wrote:
if there are different msmerges out there that exhibit different behavior, perhaps bin/po2templ.py needs to be updated to account for differing formats.
It's not msgmerge. I was on the point of writing to Bruno, then I remembered that my translation editor had thrown one of its rare wobblies on that day, while I was editing Mailman, and had produced an output file with some abnormalities (missing quotation marks).
I ran msgmerge again over the current POT, and the spaces are there in the headers in the output file.
So it looks like that was a freak error, certainly something that hasn't happened before. It might be easier all around if I just merge the translated strings into the current POT and commit that over the current translation.
What do you think?
Sorry it took me a while to work this one out. I haven't had anything like that happen before. :S
from Clytie (vi-VN, Vietnamese free-software translation team / nhóm Việt hóa phần mềm tự do) http://groups-beta.google.com/group/vi-VN
Clytie Siddall wrote:
On 27/04/2006, at 12:46 AM, Mark Sapiro wrote:
if there are different msmerges out there that exhibit different behavior, perhaps bin/po2templ.py needs to be updated to account for differing formats.
It's not msgmerge. I was on the point of writing to Bruno, then I remembered that my translation editor had thrown one of its rare wobblies on that day, while I was editing Mailman, and had produced an output file with some abnormalities (missing quotation marks).
I ran msgmerge again over the current POT, and the spaces are there in the headers in the output file.
So it looks like that was a freak error, certainly something that hasn't happened before. It might be easier all around if I just merge the translated strings into the current POT and commit that over the current translation.
What do you think?
Yes, I definitely think it would be good to update the translation (mailman.po) on the trunk.
I still like the idea of the patch I worked up for po2templ.py as it makes this more robust against possible changes in the .po headers, but I'll leave it up to Tokio to decide on that as it's his code.
On 28/04/2006, at 3:05 AM, Mark Sapiro wrote:
Yes, I definitely think it would be good to update the translation (mailman.po) on the trunk.
Done. :)
All the spaces (AFAI can see) are in the correct places. If I see any spaces lolling around on my desktop, I will smack them and send them back to the file.
from Clytie (vi-VN, Vietnamese free-software translation team / nhóm Việt hóa phần mềm tự do) http://groups-beta.google.com/group/vi-VN
On Thu, 2006-04-27 at 10:35 -0700, Mark Sapiro wrote:
Yes, I definitely think it would be good to update the translation (mailman.po) on the trunk.
Just a warning that source strings will probably change quite a bit as I convert our bin and cron scripts from getopt to optparse. I'm trying (as always) to be mindful of not gratuitously changing translatable text, but in this case it can't be avoided.
Eventually, I'd also like to change all translatable text from using %-substitutions to using $-substitutions, but I think in general we can automate that conversion (IOW, not totally invalidate all existing translations just because of that change). Anybody looking for a fun little project to work on? :)
I still like the idea of the patch I worked up for po2templ.py as it makes this more robust against possible changes in the .po headers, but I'll leave it up to Tokio to decide on that as it's his code.
I agree that it's probably the right thing to commit, but yes, let's have Tokio weigh in first.
-Barry
On 28/04/2006, at 3:35 PM, Barry Warsaw wrote:
Just a warning that source strings will probably change quite a bit as I convert our bin and cron scripts from getopt to optparse. I'm trying (as always) to be mindful of not gratuitously changing translatable text, but in this case it can't be avoided.
And in any case, translators working on the trunk branch must be aware that this _is_ the development branch and thus will continue to change. :)
The first priority is to complete our translations of the current (stable) Mailman version (2.1.8 at this stage).
Having done that, the essential job of getting the translations out to users, we take a deep breath and relax our aching brains ;).
Then, to get a good start on the next version, we can merge our translations across to the trunk branch, and update the empty and fuzzy strings in that file.
However, it's not effective use of our time to try and keep the trunk branch at 100% while it is still in development.
When we are translating any branch in active development, it's more effective to check its status once a week, for example, and update it then. This keeps our files current, without having to make constant changes.
Before the branch is released, it will go into string freeze for at least a couple of weeks, which gives us the chance to finalize our translations. There shouldn't be any changes to strings during this message freeze.
So don't panic too much about trying to keep trunk at 100%. It's not the software currently being used, it's still being changed, and you''ll get reasonable notice to update it before release. :)
from Clytie (vi-VN, Vietnamese free-software translation team / nhóm Việt hóa phần mềm tự do) http://groups-beta.google.com/group/vi-VN
On Wed, 2006-04-26 at 08:16 -0700, Mark Sapiro wrote:
Your next mail:
There is no entry for Vietnamese in the add_languages() statements in Defaults.py.in in the Release_2_1-maint branch or in the LANGUAGE_DICT entries in Defaults.py.in in the trunk.
Who should add such entries? Should I? If so, please tell me what I should do.
The comments in Defaults.py.in say in part
# Vgg: Language descriptions and charsets dictionary, any new supported # language must have a corresponding entry here.
I think this means it's up to the translator to put it there, but I'm not really familiar with Mailman i18n procedures.
Just for the record, it's fine for the translator to add an entry here for their language. Often though, new languages are donated by people who don't have commit privileges, so it should technically be done by whoever does the initial commit of the language.
-Barry
participants (4)
-
Barry Warsaw -
Clytie Siddall -
Mark Sapiro -
Tokio Kikuchi