Mixed Languages in response messages
Hi,
the response to the 'help' request of a subscriber delivers a German output except for the command 'confirm <confirmation-string>' which comes in English.
The mailman.po file looks OK to me and compiles fine, so what can be the reason?
Michael
Michael Heydekamp <my@freexp.de> wrote on 05.01.04:
the response to the 'help' request of a subscriber delivers a German output except for the command 'confirm <confirmation-string>' which comes in English.
The mailman.po file looks OK to me and compiles fine, so what can be the reason?
As there was no response so far I'm wondering if this an extremely difficult question and/or if there's any better place to ask?
Michael
The mailman.po file looks OK to me and compiles fine, so what can be the reason?
As there was no response so far I'm wondering if this an extremely difficult question and/or if there's any better place to ask?
I also noticed mixed languages response in various situations regarding Polish language. Also in the list-owner administrative interface when set to Polish some text is in Polish, and some in English, and what's more interesting, sometimes it can be in English, and the next time it can be in Polish. Maybe it depends on the phase of the Moon or strength of the wind or something... ;)
Cheers! ak
PS. Who did the translation to Polish? As there are some style errors. Like sentence shouldn't start with "Aby" because "aby" is conjunctive. I found also one mistyping.
On Tuesday 20 January 2004 19:14, Andrzej Kasperowicz wrote:
I also noticed mixed languages response in various situations regarding Polish language. Also in the list-owner administrative interface when set to Polish some text is in Polish, and some in English, and what's more interesting, sometimes it can be in English, and the next time it can be in Polish. Maybe it depends on the phase of the Moon or strength of the wind or something... ;)
Maybe the polish translation is still incomplete or a bit outdated.
PS. Who did the translation to Polish? As there are some style errors. Like sentence shouldn't start with "Aby" because "aby" is conjunctive. I found also one mistyping.
You should better ask on the mailman-i18n@python.org list, there's a good chance the polish translator will read your message.
Cheers, Simone
the response to the 'help' request of a subscriber delivers a German output except for the command 'confirm <confirmation-string>' which comes in English.
"confirm" is not translatable, because it's really a command for the interface minilanguage. E.g. you don't transalate "print" when you're writing a programming manual.
Of course "<confirmation-string>" can be translated, and in fact in italian it is, but maybe the german translator didn't think this was a good idea.
if there's any better place to ask?
There's a list devoted to Mailman translations:
mailman-i18n@python.org
Cheers, Simone
Simone Piunno <pioppo@ferrara.linux.it> wrote on 20.01.04:
the response to the 'help' request of a subscriber delivers a German output except for the command 'confirm <confirmation-string>' which comes in English.
"confirm" is not translatable, because it's really a command for the interface minilanguage. E.g. you don't transalate "print" when you're writing a programming manual.
I think you got me wrong. ;) The problem is that there *is* a translation in mailman.po already but it's not used due to some reason.
This is what I get:
----------8<----------
confirm <confirmation-string> Confirm an action. The confirmation-string is required and should be supplied by a mailback confirmation notice. English paragraph -> ^^^^^^^^^^^^^^^^^^^^^ end Beendet die Liste der Kommandos. Sinnvoll, falls Ihr Mailprogramm eine Signatur an den Nachrichtentext anhängt. German paragraph -> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ----------8<----------
So a mix of English (for the "confirm" command) and German (for the "end" command). And this is what I should get (because it's in mailman.po, and yes, I re-compiled mailman.po after I made some corrections, and the behaviour is the same also with the original file):
----------8<----------
confirm <confirmation-string> Bestätigt einen Befehl. Der Bestätigungscode ist zwingend erforderlich und muß in der Rückbestätigung übermittelt werden. German paragraph -> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ end Beendet die Liste der Kommandos. Sinnvoll, falls Ihr Mailprogramm eine Signatur an den Nachrichtentext anhängt. German paragraph -> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ----------8<----------
See?
if there's any better place to ask?
There's a list devoted to Mailman translations:
mailman-i18n@python.org
Well, I know that this list exists but having had a quick look into it it didn't make the impression to me as if this would be the right place for this particular question. It's not a translation issue (as I can translate the stuff myself), it does more look like a code and thus a developer issue to me.
I'm not too familiar with the format and the logic of mailman.po (although I made some successful changes and corrections), but it might have to do with the 'fuzzy' line here:
----------8<----------
#: Mailman/Commands/cmd_confirm.py:17 #, fuzzy ^^^^^ msgid "" ----------8<----------
I'm not sure what that does and when I remove it and re-compile the file, it doesn't change anything.
Also do I find the English text in fact in line 17 of cmd_confirm.py, but I dont't know what that means either.
Michael
On Tuesday 20 January 2004 23:41, Michael Heydekamp wrote:
Well, I know that this list exists but having had a quick look into it it didn't make the impression to me as if this would be the right place for this particular question. It's not a translation issue (as I can translate the stuff myself), it does more look like a code and thus a developer issue to me. I'm not too familiar with the format and the logic of mailman.po (although I made some successful changes and corrections), but it might have to do with the 'fuzzy' line here:
----------8<----------
#: Mailman/Commands/cmd_confirm.py:17 #, fuzzy
that "fuzzy" tag means this translation is *disabled* (the software wil pretend it's not there). The tag is automatically inserted by the msgmerge tool whenever a translation is associated to a new original string using a best effort guess. So, until the translator edits the file, confirming the fuzzy association is good (e.g removing the fuzzy tag) and/or adding improvements, this translation won't be used. And yes, this *is* a question for the -i18n list, because the internal format of a .po file is more familiar to translators than to coders. BTW, try to add a -v when you compile the .po file, e.g.
msgfmt -v -o mailman.mo mailman.po
You should see something like this:
1196 translated messages, 18 fuzzy translations, 65 untranslated messages.
So you can easily know the status of the translation (the line above is related to the most recent copy of the german po file I have on my machine).
Cheers, Simone
Simone Piunno <pioppo@ferrara.linux.it> wrote on 21.01.04:
On Tuesday 20 January 2004 23:41, Michael Heydekamp wrote:
I'm not too familiar with the format and the logic of mailman.po (although I made some successful changes and corrections), but it might have to do with the 'fuzzy' line here:
[...]
that "fuzzy" tag means this translation is *disabled* (the software wil pretend it's not there). The tag is automatically inserted by the msgmerge tool whenever a translation is associated to a new original string using a best effort guess. So, until the translator edits the file, confirming the fuzzy association is good (e.g removing the fuzzy tag) and/or adding improvements, this translation won't be used.
Ah, thanks for the explanation.
But as I said: Even if I remove the tag and recompile the file, the translation is still not used. What's wrong?
And yes, this *is* a question for the -i18n list, because the internal format of a .po file is more familiar to translators than to coders.
Ok. Probably we can clarify this particular question here, but I will have more ones which I will then raise in -i18n. OK? :)
BTW, try to add a -v when you compile the .po file, e.g.
Thx for the hint, I had just used -o so far.
Michael
participants (3)
-
Andrzej Kasperowicz
-
Michael Heydekamp
-
Simone Piunno