[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patch for bison/po/es.po
From: |
Martin v. Loewis |
Subject: |
Re: Patch for bison/po/es.po |
Date: |
21 Mar 2002 11:54:04 +0100 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 |
Akim Demaille <address@hidden> 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