| I installed the following patch into bison-1_29-branch/po/; it is | taken from Debian's bison_1.34-1.diff.gz. Could you please ensure | that this patch appears in the next Spanish translation for Bison at | www.iro.umontreal.ca? Thanks. | | Index: es.po | =================================================================== | RCS file: /cvsroot/bison/bison/po/es.po,v | retrieving revision 1.48.2.55 | retrieving revision 1.48.2.56 | diff -p -u -r1.48.2.55 -r1.48.2.56 | --- es.po 20 Mar 2002 08:48:08 -0000 1.48.2.55 | +++ es.po 20 Mar 2002 22:00:51 -0000 1.48.2.56 | @@ -67,7 +67,7 @@ msgstr "error grave: %s\n" | #, fuzzy, c-format | msgid "Conflict in state %d between rule %d and token %s resolved as %s.\n" | msgstr "" | -"El conflicto en el estado %s entre la regla %d y el terminal %s se resuelve " | +"El conflicto en el estado %d entre la regla %d y el terminal %s se resuelve " | "como %s.\n" | | #: src/conflicts.c:94 src/conflicts.c:119
I don't get it! I kept on repairing and repairing this file. How could it escape! By the way, I never had any answer to the following message. Could someone at TP handle it too? Thanks!
------------------------------------------------------------
Sender: akim@nostromo.lrde.epita.fr To: French traduc@traduc.org Cc: Michel Robitaille robitail@IRO.UMontreal.CA Subject: Bison 1.33 From: Akim Demaille akim@epita.fr Date: 11 Mar 2002 20:25:41 +0100 Message-ID: mv4pu2a29fu.fsf@nostromo.lrde.epita.fr User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Lines: 23 Xref: nostromo.lrde.epita.fr messages.sent:10628
Hi!
This translation is obviously wrong:
@@ -300,17 +300,17 @@
#: src/lex.c:438 msgid "use "..." for multi-character literal tokens" -msgstr "utilisez "..." pour les terminaux litéraux de plusieurs caractères" +msgstr "utilisez «...» pour les terminaux litéraux de plusieurs caractères"
as I'm referring exactly to ".
And BTW, this is not what you mean either
#: lib/getopt.c:899 #, c-format msgid "%s: option `-W %s' doesn't allow an argument\n" -msgstr "%s: l'option `-W %s' n'admet pas d'argument\n" +msgstr "%s: l'option «-W %s« n»admet pas d'argument\n"
Please, update this so that I can release Bison 1.34.
Afficher les réponses par date
Akim Demaille akim@epita.fr writes:
| #, fuzzy, c-format | msgid "Conflict in state %d between rule %d and token %s resolved as %s.\n" | msgstr "" | -"El conflicto en el estado %s entre la regla %d y el terminal %s se resuelve " | +"El conflicto en el estado %d entre la regla %d y el terminal %s se resuelve " | "como %s.\n" | | #: src/conflicts.c:94 src/conflicts.c:119
I don't get it! I kept on repairing and repairing this file. How could it escape!
As Santiago explains: this string is marked fuzzy, meaning that the translator has not completed translation. There is no need to do anything about this - the translator will eventually get to it and update the translation.
If you still get problems with it, it might be because you instruct msgfmt to include fuzzy translations as well. Please don't do that - fuzzy translations are not for consumption by users. GNU msgfmt, by default, will ignore fuzzy messages - you would have to pass -f explicitly to request them. So if you currently use this option, please change the build process appropriately.
If you think there is a different problem with this translation, please explain what that is.
This translation is obviously wrong:
@@ -300,17 +300,17 @@
#: src/lex.c:438 msgid "use "..." for multi-character literal tokens" -msgstr "utilisez "..." pour les terminaux litéraux de plusieurs caractères" +msgstr "utilisez «...» pour les terminaux litéraux de plusieurs caractères"
as I'm referring exactly to ".
Did you mean the patch in the reverse direction?
In any case, please try not to interfere with the translators work. If there are bugs, it is normally best to include the catalog anyway. Many catalogs will have grammatical and contextual errors in them - there is no way you could find these errors. Instead, users of your package will find them. Don't be upset when they report them - just forward them to the respective translator (it clearly is nor your fault, after all).
If one translator is unresponsive, we'll try to settle things (possibly asking the leader of the team to reassign the package to somebody else). If you cannot accept shipping incorrect translations that you know about, just mark the ones you don't like as 'fuzzy'. If you feel that there are too many broken translations in a catalog, you could also remove the catalog from the distribution - but we'd prefer to be notified in this case.
For the specific French translation, I'll forward this to Michel Robitaille.
Regards, Martin
"Martin" == Martin v Loewis martin@v.loewis.de writes:
I don't get it! I kept on repairing and repairing this file. How could it escape!
Martin> As Santiago explains: this string is marked fuzzy, meaning Martin> that the translator has not completed translation. There is no Martin> need to do anything about this - the translator will Martin> eventually get to it and update the translation.
No. As I tried to explain, this string was not marked fuzzy. I kept on repairing it on my copy, but since the TP uses 0.11, it seems that the string is *now* marked as fuzzy.
This translation is obviously wrong:
@@ -300,17 +300,17 @@
#: src/lex.c:438 msgid "use "..." for multi-character literal tokens" -msgstr "utilisez "..." pour les terminaux litéraux de plusieurs caractères" +msgstr "utilisez «...» pour les terminaux litéraux de plusieurs caractères"
as I'm referring exactly to ".
Martin> Did you mean the patch in the reverse direction?
I mean the newest translation is +, the old was -, and the new one is wrong.
Martin> In any case, please try not to interfere with the translators Martin> work.
Then consider I'm not a Bison maintainer, I'm someone who reports translation problems.
Martin> If there are bugs, it is normally best to include the catalog Martin> anyway. Many catalogs will have grammatical and contextual Martin> errors in them - there is no way you could find these Martin> errors.
I don't really care about these. I care about those that are wrong, not bad. I care about Bison asking for English quotes, and not demandant pour des guillemets français :).
Martin> Instead, users of your package will find them.
I'm a user!
Martin> Don't be upset when they report them - just forward them to Martin> the respective translator (it clearly is nor your fault, after Martin> all).
I'm sorry if I was harsh. I did not mean it, nor did I realize I was.
Akim Demaille akim@epita.fr writes:
No. As I tried to explain, this string was not marked fuzzy. I kept on repairing it on my copy, but since the TP uses 0.11, it seems that the string is *now* marked as fuzzy.
I see. If the translator had removed the c-format marker from the catalog, the robot would not catch this case. As you say: with gettext 0.11, this problem is gone - in particular since the robot now merges each submission with the template.
Regards, Martin
-
Akim Demaille -
martin＠v.loewis.de