[GRASS-dev] lib/gis/*.c: Extra calls to sprintf () just before G_warning ()

GRASS GIS GRASS GIS developer
1

  There's no need to use sprintf () along with G_warning (), since
  the latter is already capable of the printf ()-style formatting.

  Also, the following are /not/ equivalent fragments of code:

   G_warning (FMT, <arguments...>);

   sprintf (s, FMT, <arguments...>);
   G_warning (s);

  Instead, the former is equivalent to the following:

   sprintf (s, FMT, <arguments...>);
   G_warning ("%s", s);

  While the latter behaves differently should any percent signs
  (`%') be put into `s' as a result of sprintf ().

  Hopefully, the following patch will resolve the issue.

  A few notes regarding i18n:

  * the typos and misspellings are to be fixed with a separate
    patch; that one should probably update locale/ as well;

  * I've introduced a few more _() invocations, as I deemed
    appropriate;

  * the code like the following could bring all the sorts of woe
    upon the heads of unsuspecting translators (this issue may
    deserve a mention on Trac.)

--cut--
      sprintf(buf,
        _("Unable to read header file for raster map <%s@%s>."),
        name, mapset);
      tail = buf + strlen(buf);
      sprintf(tail, _(" It is a reclass of raster map <%s@%s> "),
        real_name, real_mapset);
      tail = buf + strlen(buf);
      if (!G_find_cell(real_name, real_mapset))
    sprintf(tail, _("which is missing."));
      else
    sprintf(tail, _("whose header file can't be opened."));
      G_warning ("%s", buf);
      return -1;
--cut--

Index: lib/gis/put_cellhd.c

--- lib/gis/put_cellhd.c (revision 36445)
+++ lib/gis/put_cellhd.c (working copy)
@@ -23,8 +23,7 @@
     if (!(fd = G_fopen_new("cellhd", name))) {
   char buf[1024];

- sprintf(buf, _("Unable to create header file for [%s]"), name);
- G_warning(buf);
+ G_warning (_("Unable to create header file for [%s]"), name);
   return -1;
     }

Index: lib/gis/put_title.c

--- lib/gis/put_title.c (revision 36445)
+++ lib/gis/put_title.c (working copy)
@@ -25,10 +25,9 @@
     in = out = 0;
     in = G_fopen_old("cats", name, mapset);
     if (!in) {
- sprintf(buf,
- _("category information for [%s] in [%s] missing or invalid"),
- name, mapset);
- G_warning(buf);
+ G_warning (_("category information for [%s] in [%s]"
+ " missing or invalid"),
+ name, mapset);
   return -1;
     }

@@ -36,8 +35,7 @@
     out = fopen(tempfile, "w");
     if (!out) {
   fclose(in);
- sprintf(buf, _("G_put_title - can't create a temp file"));
- G_warning(buf);
+ G_warning (_("G_put_title - can't create a temp file"));
   return -1;
     }

@@ -53,25 +51,22 @@

     /* must be #cats line, title line, and label for cat 0 */
     if (line < 3) {
- sprintf(buf, _("category information for [%s] in [%s] invalid"), name,
- mapset);
- G_warning(buf);
+ G_warning (_("category information for [%s] in [%s] invalid"),
+ name, mapset);
   return -1;
     }

     in = fopen(tempfile, "r");
     if (!in) {
- sprintf(buf, _("G_put_title - can't reopen temp file"));
- G_warning(buf);
+ G_warning (_("G_put_title - can't reopen temp file"));
   return -1;
     }

     out = G_fopen_new("cats", name);
     if (!out) {
   fclose(in);
- sprintf(buf, _("can't write category information for [%s] in [%s]"),
- name, mapset);
- G_warning(buf);
+ G_warning (_("can't write category information for [%s] in [%s]"),
+ name, mapset);
   return -1;
     }

Index: lib/gis/quant_io.c

--- lib/gis/quant_io.c (revision 36445)
+++ lib/gis/quant_io.c (working copy)
@@ -86,9 +86,8 @@
   return 0;
     G_get_fp_range_min_max(&fprange, &dMin, &dMax);
     if (G_is_d_null_value(&dMin) || G_is_d_null_value(&dMax)) {
- sprintf(buf, _("The floating data range for %s@%s is empty"), name,
- mapset);
- G_warning(buf);
+ G_warning (_("The floating data range for %s@%s is empty"),
+ name, mapset);
   return -3;
     }

@@ -96,9 +95,8 @@
   return 0;
     G_get_range_min_max(&range, &min, &max);
     if (G_is_c_null_value(&min) && G_is_c_null_value(&max)) {
- sprintf(buf, _("The integer data range for %s@%s is empty"), name,
- mapset);
- G_warning(buf);
+ G_warning (_("The integer data range for %s@%s is empty"),
+ name, mapset);
   return -3;
     }

@@ -121,10 +119,9 @@
     G_quant_free(quant);

     if (G_raster_map_type(name, mapset) == CELL_TYPE) {
- sprintf(buf,
- "G__quant_import: attempt to open quantization table for CELL_TYPE file [%s] in mapset {%s]",
- name, mapset);
- G_warning(buf);
+ G_warning (_("G__quant_import: attempt to open quantization"
+ " table for CELL_TYPE file [%s] in mapset {%s]"),
+ name, mapset);
   return -2;
     }

@@ -164,9 +161,8 @@
   err = "empty";
     }

- sprintf(buf,
- _("quantization file [%s] in mapset [%s] %s"), name, mapset, err);
- G_warning(buf);
+ G_warning (_("quantization file [%s] in mapset [%s] %s"),
+ name, mapset, err);

     return 0;
}
Index: lib/gis/range.c

--- lib/gis/range.c (revision 36445)
+++ lib/gis/range.c (working copy)
@@ -185,8 +185,8 @@
   error:
     if (fd > 0)
   close(fd);
- sprintf(buf, _("can't read f_range file for [%s in %s]"), name, mapset);
- G_warning(buf);
+ G_warning (_("can't read f_range file for [%s in %s]"),
+ name, mapset);
     return -1;
}

@@ -236,10 +236,9 @@
   DCELL dmin, dmax;

   if (G_read_quant(name, mapset, &quant) < 0) {
- sprintf(buf,
- "G_read_range(): can't read quant rules for fp map %s@%s",
- name, mapset);
- G_warning(buf);
+ G_warning (_("G_read_range(): can't read quant rules"
+ " for fp map %s@%s"),
+ name, mapset);
       return -1;
   }
   if (G_quant_is_truncate(&quant) || G_quant_is_round(&quant)) {
@@ -301,8 +300,8 @@
   error:
     if (fd)
   fclose(fd);
- sprintf(buf, _("can't read range file for [%s in %s]"), name, mapset);
- G_warning(buf);
+ G_warning (_("can't read range file for [%s in %s]"),
+ name, mapset);
     return -1;
}

Index: lib/gis/get_cellhd.c

--- lib/gis/get_cellhd.c (revision 36445)
+++ lib/gis/get_cellhd.c (working copy)
@@ -77,7 +77,7 @@
     sprintf(tail, _("which is missing."));
       else
     sprintf(tail, _("whose header file can't be opened."));
- G_warning(buf);
+ G_warning ("%s", buf);
       return -1;
   }
     }
Index: lib/gis/quant_rw.c

--- lib/gis/quant_rw.c (revision 36445)
+++ lib/gis/quant_rw.c (working copy)
@@ -70,9 +70,9 @@
     G_quant_truncate(&quant);
     /* quantize the map */
     if (G_write_quant(name, mapset, &quant) < 0) {
- sprintf(buf, "G_truncate_fp_map: can't write quant rules for map %s",
- name);
- G_warning(buf);
+ G_warning (_("G_truncate_fp_map: can't write quant rules"
+ " for map %s"),
+ name);
   return -1;
     }
     return 1;
@@ -87,9 +87,9 @@
     G_quant_round(&quant);
     /* round the map */
     if (G_write_quant(name, mapset, &quant) < 0) {
- sprintf(buf, "G_truncate_fp_map: can't write quant rules for map %s",
- name);
- G_warning(buf);
+ G_warning (_("G_truncate_fp_map: can't write quant rules"
+ " for map %s"),
+ name);
   return -1;
     }
     return 1;
@@ -118,15 +118,14 @@
     struct FPRange fp_range;

     if (G_read_fp_range(name, mapset, &fp_range) < 0) {
- sprintf(buf, "G_quantize_fp_map: can't read fp range for map %s",
- name);
- G_warning(buf);
+ G_warning (_("G_quantize_fp_map: can't read fp range for map %s"),
+ name);
   return -1;
     }
     G_get_fp_range_min_max(&fp_range, &d_min, &d_max);
     if (G_is_d_null_value(&d_min) || G_is_d_null_value(&d_max)) {
- sprintf(buf, "G_quantize_fp_map: raster map %s is empty", name);
- G_warning(buf);
+ G_warning (_("G_quantize_fp_map: raster map %s is empty"),
+ name);
   return -1;
     }
     return G_quantize_fp_map_range(name, mapset, d_min, d_max, min, max);
@@ -166,10 +165,9 @@
     G_quant_add_rule(&quant, d_min, d_max, min, max);
     /* quantize the map */
     if (G_write_quant(name, mapset, &quant) < 0) {
- sprintf(buf,
- "G_quantize_fp_map_range: can't write quant rules for map %s",
- name);
- G_warning(buf);
+ G_warning (_("G_quantize_fp_map_range: can't write quant rules"
+ " for map %s"),
+ name);
   return -1;
     }
     return 1;
@@ -203,8 +201,8 @@
     char buf[300];

     if (G_raster_map_type(name, mapset) == CELL_TYPE) {
- sprintf(buf, _("Cannot write quant rules: map %s is integer"), name);
- G_warning(buf);
+ G_warning (_("Cannot write quant rules: map %s is integer"),
+ name);
   return -1;
     }

@@ -212,8 +210,7 @@

     /* first actually write the rules */
     if (G__quant_export(name, mapset, quant) < 0) {
- sprintf(buf, _("Cannot write quant rules for map %s"), name);
- G_warning(buf);
+ G_warning (_("Cannot write quant rules for map %s"), name);
   return -1;
     }

--
FSF associate member #7257

2

Hello Ivan,
It's good to see Your internationalisation efforts, still I spotted
one huge NO-NO in Your patch - one should NEVER split strings marked
for translation. Some languages may require opposite word order in
sentence or even different sentence for each case. Also if translating
such sentences is possible, it's hard, as it's not possible to see
whole sentence just it's start or end.

Also if somebody is taking internationalisation in GRASS serious, he
needs to add context to more complex strings. More about making
programs internationalisation-friendly is possible to read in gettext
manual [1].

WBR,
Maris.

1. http://www.gnu.org/software/gettext/manual/gettext.html#Sources

2009/3/22, Ivan Shmakov <oneingray@gmail.com>:

      sprintf(tail, _(" It is a reclass of raster map <%s@%s> "),
        real_name, real_mapset);
      tail = buf + strlen(buf);
      if (!G_find_cell(real_name, real_mapset))
    sprintf(tail, _("which is missing."));
      else
    sprintf(tail, _("whose header file can't be opened."));

===================================================================
--- lib/gis/get_cellhd.c (revision 36445)
+++ lib/gis/get_cellhd.c (working copy)
@@ -77,7 +77,7 @@
     sprintf(tail, _("which is missing."));
       else
     sprintf(tail, _("whose header file can't be opened."));
- G_warning(buf);
+ G_warning ("%s", buf);

3

Maris Nartiss <maris.gis@gmail.com> writes:

[...]

>> * the code like the following could bring all the sorts of woe upon
>> the heads of unsuspecting translators (this issue may deserve a
>> mention on Trac.)

>> --cut--
>> sprintf(buf,
>> _("Unable to read header file for raster map <%s@%s>."),
>> name, mapset);
>> tail = buf + strlen(buf);
>> sprintf(tail, _(" It is a reclass of raster map <%s@%s> "),
>> real_name, real_mapset);
>> tail = buf + strlen(buf);
>> if (!G_find_cell(real_name, real_mapset))
>> sprintf(tail, _("which is missing."));
>> else
>> sprintf(tail, _("whose header file can't be opened."));
>> G_warning ("%s", buf);
>> return -1;
>> --cut--

> Hello Ivan, It's good to see Your internationalisation efforts,

  It's more about cleaning the things up than i18n, actually.

> still I spotted one huge NO-NO in Your patch - one should NEVER split
> strings marked for translation. Some languages may require opposite
> word order in sentence or even different sentence for each case. Also
> if translating such sentences is possible, it's hard, as it's not
> possible to see whole sentence just it's start or end.

  Yes, that's why I've pointed the code fragment above, as it may
  easily be unsuitable for translation into some languages.
  Unfortunately, I have too little spare time nowadays to fix the
  issues like this myself, so I've just left the things untouched.

  Should I put the issue into Trac?

  ... Or was your remark about the use of string literals'
  concatenation in my patch? But, then, both the C compiler /and/
  gettext do support these properly. Essentially, the C compiler
  isn't expected to treat, e. g., the following fragments
  differently:

   const char *hello = ("Hello, world!");

   const char *hello = ("He" "llo,"
                        " world!"); /* NB: same as "Hello, world!" */

  You may consider, e. g., the following change:

--- lib/gis/put_title.c (revision 36445)
+++ lib/gis/put_title.c (working copy)
@@ -25,10 +25,9 @@
     in = out = 0;
     in = G_fopen_old("cats", name, mapset);
     if (!in) {
- sprintf(buf,
- _("category information for [%s] in [%s] missing or invalid"),
- name, mapset);
- G_warning(buf);
+ G_warning (_("category information for [%s] in [%s]"
+ " missing or invalid"),
+ name, mapset);
   return -1;
     }

  Despite the string appears ``split'', gettext still produces the
  correct result:

--cut: locale/templates/grasslibs.pot --
#: ../lib/gis/put_title.c:28
#, c-format
msgid "category information for [%s] in [%s] missing or invalid"
msgstr ""
--cut: locale/templates/grasslibs.pot --

[...]

--
FSF associate member #7257

4

Ah, sorry Ivan.
My brain somehow skipped Your remarks about translation and was just
reading bad code.
I once was translating GRASS to Latvian language but I soon realised
that it's nightmare to do. GUI is almost OK, still modules and libs
don't play nicely with Latvian language and it also gives too little
return for investment. Still if somebody does cosmetic changes to
GRASS modules/libs messages, it would be nice to do this time things
right.

Sorry for fuss,
Maris.

5

Ivan Shmakov wrote:

  There's no need to use sprintf () along with G_warning (), since
  the latter is already capable of the printf ()-style formatting.

  Also, the following are /not/ equivalent fragments of code:

   G_warning (FMT, <arguments...>);

   sprintf (s, FMT, <arguments...>);
   G_warning (s);

  Instead, the former is equivalent to the following:

   sprintf (s, FMT, <arguments...>);
   G_warning ("%s", s);

  While the latter behaves differently should any percent signs
  (`%') be put into `s' as a result of sprintf ().

  Hopefully, the following patch will resolve the issue.

The above is an artifact of printf-style formatting having been
retrofitted to G_warning() etc. Unsurprisingly, no-one went to the
trouble of fixing every single usage at that time :wink:

  * the code like the following could bring all the sorts of woe
    upon the heads of unsuspecting translators (this issue may
    deserve a mention on Trac.)

--cut--
      sprintf(buf,
        _("Unable to read header file for raster map <%s@%s>."),
        name, mapset);
      tail = buf + strlen(buf);
      sprintf(tail, _(" It is a reclass of raster map <%s@%s> "),
        real_name, real_mapset);
      tail = buf + strlen(buf);
      if (!G_find_cell(real_name, real_mapset))
    sprintf(tail, _("which is missing."));
      else
    sprintf(tail, _("whose header file can't be opened."));
      G_warning ("%s", buf);
      return -1;
--cut--

Please fix this, e.g.:

  G_warning(
    !G_find_cell(real_name, real_mapset)
    ? _("Unable to read header file for raster map <%s@%s>. It is a reclass of raster map <%s@%s> which is missing.")
    : _("Unable to read header file for raster map <%s@%s>. It is a reclass of raster map <%s@%s> whose header file can't be opened."),
    name, mapset);

I don't think that mentioning it on Trac is particularly helpful, as
no-one will find it unless they're specifically looking for it, in
which case they probably already know. But it's worth mentioning here,
and probably on the Wiki (if it isn't already):

The translation macro _(...) must be applied to entire messages, not
fragments. Code such as the above needs to be fixed to have the entire
message as a single string before it can be internationalised.

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

6

Maris Nartiss <maris.gis@gmail.com> writes:

[...]

> I once was translating GRASS to Latvian language but I soon realised
> that it's nightmare to do.

  The same could be said about Russian -- there just isn't a
  common dictionary to translate most of the English terms
  adequately.

  Consider the following example. The word ``location'' has no
  suitable translation into Russian (the most of the translations
  the Mueller English-Russian dictionary gives are too close to,
  say, a ``dwelling place''.) However, the word is translated in
  grassmods_ru.po as, e. g.:

#: ../imagery/i.find/main.c:63
#, c-format
msgid "usage: %s location mapset element file."
msgstr "использование: %s область набор элемент файл."

  Unfortunately, ``область'' is hardly a good translation for
  ``location'', as ``region'' readily translates into ``область'',
  too:

From Mueller English-Russian Dictionary [mueller7]:

region
   [:arrow_upper_right:ri:dʒɜn] _n.
   1) страна; край; область; округа; _перен. сфера, область;
[...]

  To distinguish between the two the translators have chosen to
  translate ``region'' as ``регион'' (also derived from Latin),
  which doesn't seem to make much difference, in my opinion.

  In the papers I co-author, I use a calque, translating
  ``location'' as ``локация'' (which, to be honest, doesn't mean
  anything in Russian), while translating ``region'' as
  ``область''.

  ... And it's not hard to guess that this discrepancy easily
  confuses my students even more than the English UI does.

> GUI is almost OK, still modules and libs don't play nicely with
> Latvian language and it also gives too little return for investment.

  I always keep in mind that, whatever the effort will be put into
  the translation, to communicate with the developers one would've
  to learn English anyway.

  To summarize, it's not that I think that the translation is
  unnecessary or harmful, but I generally consider it a
  lower-priority task.

  On the other hand, the code still should be kept clean and
  suitable for future l10n.

> Still if somebody does cosmetic changes to GRASS modules/libs
> messages, it would be nice to do this time things right.

  Surely.

> Sorry for fuss, Maris.

--
FSF associate member #7257

7

On Wed, Mar 25, 2009 at 7:42 PM, Ivan Shmakov <oneingray@gmail.com> wrote:

Maris Nartiss <maris.gis@gmail.com> writes:

[...]

> I once was translating GRASS to Latvian language but I soon realised
> that it's nightmare to do.

   The same could be said about Russian \-\- there just isn&#39;t a
   common dictionary to translate most of the English terms
   adequately\.

   Consider the following example\.  The word \`\`location&#39;&#39; has no
   suitable translation into Russian \(the most of the translations
   the Mueller English\-Russian dictionary gives are too close to,
   say, a \`\`dwelling place&#39;&#39;\.\)  However, the word is translated in
   grassmods\_ru\.po as, e\. g\.:

#: ../imagery/i.find/main.c:63
#, c-format
msgid "usage: %s location mapset element file."
msgstr "использование: %s область набор элемент файл."

   Unfortunately, \`\`область&#39;&#39; is hardly a good translation for
   \`\`location&#39;&#39;, as \`\`region&#39;&#39; readily translates into \`\`область&#39;&#39;,
   too:

>From Mueller English-Russian Dictionary [mueller7]:

region
[:arrow_upper_right:ri:dʒɜn] _n.
1) страна; край; область; округа; _перен. сфера, область;
[...]

   To distinguish between the two the translators have chosen to
   translate \`\`region&#39;&#39; as \`\`регион&#39;&#39; \(also derived from Latin\),
   which doesn&#39;t seem to make much difference, in my opinion\.

   In the papers I co\-author, I use a calque, translating
   \`\`location&#39;&#39; as \`\`локация&#39;&#39; \(which, to be honest, doesn&#39;t mean
   anything in Russian\), while translating \`\`region&#39;&#39; as
   \`\`область&#39;&#39;\.

   \.\.\. And it&#39;s not hard to guess that this discrepancy easily
   confuses my students even more than the English UI does\.

Perhaps, after agreement, the relevant terms could be
collected here:

http://grass.osgeo.org/wiki/GRASS_Translation_Glossary

Markus

8

Hello Ivan,

msgid "usage: %s location mapset element file."
msgstr "использование: %s область набор элемент файл."

   Unfortunately, \`\`область&#39;&#39; is hardly a good translation for
   \`\`location&#39;&#39;, as \`\`region&#39;&#39; readily translates into \`\`область&#39;&#39;,
   too:

hmmm... in Central Asia, область has an administrative level meaning,
and I believe they also use "rayon" (sorry no kyrillic keyboard here)
for another administrative level.
This would add confusion maybe.

>From Mueller English-Russian Dictionary [mueller7]:

region
[:arrow_upper_right:ri:dʒɜn] _n.
1) страна; край; область; округа; _перен. сфера, область;
[...]

   To distinguish between the two the translators have chosen to
   translate \`\`region&#39;&#39; as \`\`регион&#39;&#39; \(also derived from Latin\),
   which doesn&#39;t seem to make much difference, in my opinion\.

... Well, maybe this is what is needed. see below.

   In the papers I co\-author, I use a calque, translating
   \`\`location&#39;&#39; as \`\`локация&#39;&#39; \(which, to be honest, doesn&#39;t mean
   anything in Russian\), while translating \`\`region&#39;&#39; as
   \`\`область&#39;&#39;\.

hmmm... it sounds tough to get something clear. But maybe we should
think again about what region and location mean really, and not
translate from their names used in GRASS but translate from whatever
they really mean.

   \.\.\. And it&#39;s not hard to guess that this discrepancy easily
   confuses my students even more than the English UI does\.

Yeah I could be confused too... In few countries with non-latin based
alphabets (Central Asia, South Asia, South East Asia), all people I
met/worked with in GIS-related work use English GUIs and English in
communication for GIS. A Thai lecturer recently told me that QGIS in
thai is funny at best and confusing to students at worst. He just uses
all software in English and explains the English technical terms
directly upon using the software. I know this is not a GRASS GIS
example, but I find it useful here.

Maybe we hit a more philosophical question here about why we want to
translate in the first place... On one hand, do we translate terms
that are "keywords" associated with functionalities specific of GIS,
this could need no translation, or just as Ivan did with region <=>
регион is to facilitate the daily use of non latin alphabet readers. I
have met many students non latin reader from birth but recently
acquired, and they have more trouble with reading than with using
english words. Then, just learning the region keyword would be
sufficient, while it maybe written in phonetic with a different
script, their own native language script. On the other hand, do we
translate concepts/functionalities that already are well-explained and
established in the language vocabulary? If so, direct translation
should not a problem.

A second question would be to generate a standard GIS [english] <=>
GIS [insert here your language of interest] lexicon. I believe that
maybe difficult though, but maybe necessary to get through this
hurdle. Of course, a straight question coming from this would be: is
there a national GIS vocabulary accepted already? If yes, that is a
good starting point.

sorry, that is a bit long,
Yann

--
Yann Chemin
Mobile: +33 (06) 10 11 39 26
Home: +33 (02) 35 27 08 20,
Address: Gite de Mortagne,
16 rue de la chenaie,
76110 Bec de Mortagne,
France

Perso: http://www.freewebs.com/ychemin
YiKingDo: http://yikingdo.unblog.fr/

9

On Wed, Mar 25, 2009 at 9:47 PM, Yann Chemin <yann.chemin@gmail.com> wrote:
...

A second question would be to generate a standard GIS [english] <=>
GIS [insert here your language of interest] lexicon. I believe that
maybe difficult though, but maybe necessary to get through this
hurdle.

Already started :slight_smile:

I had proposed once the "OSGeo Multilanguage Dictionary":
http://wiki.osgeo.org/wiki/OSGeo_Multilanguage_Dictionary

which was then set up here:
http://geodictionary.osgeo.org

Till rather empty but open to the public and to be improved.

Markus

10

"YC" == Yann Chemin <yann.chemin@gmail.com> writes:

>> msgid "usage: %s location mapset element file."
>> msgstr "использование: %s область набор элемент файл."

>> Unfortunately, ``область'' is hardly a good translation for
>> ``location'', as ``region'' readily translates into ``область'',
>> too:

> hmmm... in Central Asia, область has an administrative level meaning,
> and I believe they also use "rayon" (sorry no kyrillic keyboard here)
> for another administrative level. This would add confusion maybe.

  I doubt it could. At least, it doesn't sounds confusing when
  one speaks of, e. g., об исследованиях в этой области (about
  research in this field), or о пересекающихся областях (about
  intersecting regions.)

>> >From Mueller English-Russian Dictionary [mueller7]:

>> region
>> [:arrow_upper_right:ri:dʒɜn] _n.
>> 1) страна; край; область; округа; _перен. сфера, область;

[...]

>> In the papers I co-author, I use a calque, translating ``location''
>> as ``локация'' (which, to be honest, doesn't mean anything in
>> Russian), while translating ``region'' as ``область''.

> hmmm... it sounds tough to get something clear. But maybe we should
> think again about what region and location mean really, and not
> translate from their names used in GRASS but translate from whatever
> they really mean.

  IIUC, ``spatial region'' corresponds to ``пространственная
  область'' (or ``область пространства'', literally: ``region of
  space''), at least when it comes to physics. And is there a
  term closer to the GRASS ``region'' than ``spatial region''?

  On the other hand, ``location'' is just a placeholder for a set
  of parameters (mainly, the coordinate system description), and
  the name for this set (by now) doesn't match its purpose too
  well. Therefore, I believe that there's no point in trying to
  preserve the meaning of the word alone, as it has a specific,
  barely related, meaning in the context of GRASS.

  With no meaning to save, I've chosen to preserve (to the extent
  possible) the graphics and pronunciation of the word instead.
  I've also relied upon the established Latin-to-Russian
  correspondence conventions (to the extent I understand them.)

>> ... And it's not hard to guess that this discrepancy easily confuses
>> my students even more than the English UI does.

> Yeah I could be confused too... In few countries with non-latin based
> alphabets (Central Asia, South Asia, South East Asia), all people I
> met/worked with in GIS-related work use English GUIs and English in
> communication for GIS. A Thai lecturer recently told me that QGIS in
> thai is funny at best and confusing to students at worst. He just
> uses all software in English and explains the English technical terms
> directly upon using the software. I know this is not a GRASS GIS
> example, but I find it useful here.

  Actually, it may depend on the language. Whenever there a
  language with an existing tradition of naming a particular
  phenomenon in a particular way, it makes sense to give similar
  phenomena similar names. OTOH, if there's no such a tradition,
  the name should be borrowed, but still respecting the target
  language and its (more general, this time) traditions.

  E. g., there's a little sense in calque ``location'' as
  ``локейшн'' (by the means of transcription), or as ``локатион''
  (by the means of transliteration.) However, should we scan the
  dictionary, we'll easily find the following:

action акция
hallucination галлюцинация
nation нация
...

  Thus, to respect the tradition, we've to calque ``location'' as
  ``локация''.

  (But, as one might guess, the contemporary Russian language
  contains a vast amount of loan words which were quite ignorant
  to the traditions at the time they were introduced to the
  language.)

> Maybe we hit a more philosophical question here about why we want to
> translate in the first place... On one hand, do we translate terms
> that are "keywords" associated with functionalities specific of GIS,
> this could need no translation, or just as Ivan did with region <=>
> регион

  But I didn't!

> is to facilitate the daily use of non latin alphabet readers. I have
> met many students non latin reader from birth but recently acquired,
> and they have more trouble with reading than with using english
> words. Then, just learning the region keyword would be sufficient,
> while it maybe written in phonetic with a different script, their own
> native language script. On the other hand, do we translate
> concepts/functionalities that already are well-explained and
> established in the language vocabulary? If so, direct translation
> should not a problem.

  I believe that it's the case of the ``region'' to ``область''
  translation.

[...]

--
FSF associate member #7257

11

"IS" == Ivan Shmakov <oneingray@gmail.com> writes:

IS> There's no need to use sprintf () along with G_warning (), since
IS> the latter is already capable of the printf ()-style formatting.

[...]

IS> Hopefully, the following patch will resolve the issue.

[...]

  Since there were no objections, I've committed the change as
  r36587.

http://trac.osgeo.org/grass/changeset/36587

--
FSF associate member #7257