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

[Ivan Shmakov]

>>>>> Maris Nartiss <maris.gis at 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