>>>>> Maris Nartiss <maris....@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
   [↗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
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Reply via email to