On Thu, Jun 18, 2015 at 10:08 AM, Moritz Lennert <
mlennert@club.worldonline.be> wrote:
On 18/06/15 15:48, Vaclav Petras wrote:
On Wed, Jun 17, 2015 at 10:14 AM, <svn_grass@osgeo.org
<mailto:svn_grass@osgeo.org>> wrote:
>
> Modified: grass/trunk/locale/po/grasslibs_fr.po
> ===================================================================
> --- grass/trunk/locale/po/grasslibs_fr.po 2015-06-17 13:53:52
UTC (rev 65496)
> +++ grass/trunk/locale/po/grasslibs_fr.po 2015-06-17 14:14:56
UTC (rev 65497)
> @@ -1909,7 +1909,7 @@
> #: ../lib/init/grass.py:130 ../lib/gis/parser.c:599
> #, fuzzy
> msgid "ERROR"
> -msgstr "ERREUR :"
> +msgstr "ERREUR: "
Hi Mortitz, I'm not experienced with translations but it seems to me
that the translations doesn't need to be fuzzy
Don't know about the fuzzy, I didn't touch that.
As I said my experience is limited but I though that when you translate the
string manually, you remove fuzzy.
and it should not contain
colon and space but only "ERREUR".
Well lib/gis/error.c, l 360ff define:
prefix_std[0] = "";
prefix_std[1] = _("WARNING: ");
prefix_std[2] = _("ERROR: ");
According to your commit there is "ERROR: " but also "ERROR" somewhere.
"ERROR: " should be translated as "ERREUR: " while "ERROR" as "ERREUR".
That's what I was trying to say.
https://trac.osgeo.org/grass/changeset/65497
so I guess the translation should also have the colon and space. We could
do something like this:
char *postfix
postfix = ": "
prefix_std[0] = "";
prefix_std[1] = _("WARNING%s", postfix);
prefix_std[2] = _("ERROR%s", postfix);
That's unnecessary complicated and it doesn't solve all issues as you note
below. Having two different strings, with and without colon&space, should
account for most of the cases (the state we have now).
But then again, maybe there are different rules of how to position colons
and spaces according to locales.
I don't know the current situation but ideally, the error message should be
composed using [in Python syntax]:
_("ERROR: %s") % msg
rather then
_("ERROR: ") + msg
But this would require two step construction of the message since `msg`
again will have again variable parts and it might be too complex or too
cumbersome (especially in C unless there is some gettext feature which
would help us).
Moritz