[GRASS-dev] temporal: gettext warnings

GRASS GIS GRASS GIS developer
1

Hi,

`temporal` modules produces a lot of gettext warnings

cd locale
make pot
...
../lib/python/temporal/datetime_math.py:227: warning: 'msgid' format
string with unnamed arguments cannot be properly localized:
                                                      The translator
cannot reorder the arguments.
                                                      Please consider
using a format string with named arguments,
                                                      and a mapping
instead of a tuple for the arguments.
../lib/python/temporal/abstract_map_dataset.py:167: warning: 'msgid'
format string with unnamed arguments cannot be properly localized:
                                                             The
translator cannot reorder the arguments.
                                                             Please
consider using a format string with named arguments,
                                                             and a
mapping instead of a tuple for the arguments.
../lib/python/temporal/abstract_map_dataset.py:169: warning: 'msgid'
format string with unnamed arguments cannot be properly localized:
                                                             The
translator cannot reorder the arguments.
                                                             Please
consider using a format string with named arguments,
                                                             and a
mapping instead of a tuple for the arguments.
...

They are harmless, anyway they should be fixed. They are caused by the
fact that the strings marked for translation contains more formatting
marks. They could be fixed by splitting the message [1] or using named
convention [2].

Martin

[1] http://trac.osgeo.org/grass/changeset/50514#file0
[2] http://trac.osgeo.org/grass/changeset/50514#file2

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

2

Martin Landa wrote:

They could be fixed by splitting the message [1] or using named
convention [2].

[1] is the wrong thing to do (and that particular example should be
reverted). It eliminates the warning without addressing the issue
which caused the warning.

Warnings provide clues as to how the code can be improved. They
shouldn't be silenced by making the code worse.

If it isn't possible to eliminate a warning without degrading the
code, then the warning should just be allowed to happen.

In Python code, using named substitutions is the right approach; it's
guaranteed to be supported by any version of Python which will work
with GRASS. With C code, not all platforms support numbered
specifications, but I don't think that xgettext warns about that.

--
Glynn Clements <glynn@gclements.plus.com>

3

Hi,

2012/1/30 Glynn Clements <glynn@gclements.plus.com>:

They could be fixed by splitting the message [1] or using named
convention [2].

[1] is the wrong thing to do (and that particular example should be
reverted). It eliminates the warning without addressing the issue
which caused the warning.

Warnings provide clues as to how the code can be improved. They
shouldn't be silenced by making the code worse.

I am not sure if we are speaking about same thing.

Index: grass/branches/develbranch_6/gui/wxpython/gmodeler/model.py

--- a/grass/branches/develbranch_6/gui/wxpython/gmodeler/model.py
+++ b/grass/branches/develbranch_6/gui/wxpython/gmodeler/model.py
@@ -386,5 +386,5 @@
                                 break
                         if report:
- errList.append(_("%s: undefined variable
'%s'") % (cmd[0], var))
+ errList.append(cmd[0] + ": " +
_("undefined variable '%s'") % var)
             ### TODO: check variables in file only optionally
             ### errList += self._substituteFile(action, checkOnly = True)
@@ -448,5 +448,5 @@
                 var = sval.group(2).strip()[1:] # ignore '%'
                 cmd = item.GetLog(string = False)[0]
- errList.append(_("%s: undefined variable '%s'") % (cmd, var))
+ errList.append(cmd + ": " + _("undefined variable '%s'") % var)

             if not checkOnly:

such changes doesn't eliminate any kind of warnings...

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

4

Martin Landa wrote:

../lib/python/temporal/datetime_math.py:227: warning: 'msgid' format
string with unnamed arguments cannot be properly localized:
The translator cannot reorder the arguments.

>> They could be fixed by splitting the message [1] ...

> [1] is the wrong thing to do ...

I am not sure if we are speaking about same thing.

I'm talking about "splitting the message".

IIUC, the issue relates to strings with more than one substitution. If
the substitutions are matched with parameters by position (i.e. the
first substitution uses the first parameter, etc), the translated
string cannot have the parameters in a different order, even if that
would be appropriate for a particular language.

Splitting the message (so that each translated string contains a
single substitution) might eliminate the warnings (I don't know
whether it does, but I assumed that was the idea behind the "splitting
the message" suggestion), but it won't do anything about the issue
which caused the warning.

--
Glynn Clements <glynn@gclements.plus.com>

5

Hi,
using named convection[1] suggested by Martin is the correct solution?

http://trac.osgeo.org/grass/changeset/50514#file2

Best regards
Soeren

2012/1/30 Glynn Clements <glynn@gclements.plus.com>:

Martin Landa wrote:

../lib/python/temporal/datetime_math.py:227: warning: 'msgid' format
string with unnamed arguments cannot be properly localized:
The translator cannot reorder the arguments.

>> They could be fixed by splitting the message [1] ...

> [1] is the wrong thing to do ...

I am not sure if we are speaking about same thing.

I'm talking about "splitting the message".

IIUC, the issue relates to strings with more than one substitution. If
the substitutions are matched with parameters by position (i.e. the
first substitution uses the first parameter, etc), the translated
string cannot have the parameters in a different order, even if that
would be appropriate for a particular language.

Splitting the message (so that each translated string contains a
single substitution) might eliminate the warnings (I don't know
whether it does, but I assumed that was the idea behind the "splitting
the message" suggestion), but it won't do anything about the issue
which caused the warning.

--
Glynn Clements <glynn@gclements.plus.com>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev