I see your point, although it is a bit different than the issue I am
raising. By a "variable" I simply meant a linguistic description of a
menu item (command) which may have to vary in its grammatical form when
that item occurs in several locations and/or contexts of the same UI.
Proper translation of such a description would require some form of
acknowledgment that multiple occurrences of the same command may require
multiple descriptions.
Granted it would multiply strings and the bulk of translation would
increase, but...that is very little in comparison to the outrageous
amount of time a translator has to spent on putting together the bits
and pieces spread around opengrok, po's, localize.sdf, ui, etc. When I
look at the allocation of my energy and time as a translator in this
project, translation is almost last thing I'm doing...
So...
Let's have ten times more words, if needed, and let have in-place
translation, and we'll be 50 if not 100% ahead of where we are right now.
Aivaras
2013.09.03 22:25, Ricardo Berlasso rašė:
2013/9/3 Aivaras Stepukonis <[email protected]>
That is exactly my point - ethnocentrism. One determines that a certain
term is a grammatical constant in his/her language and needs not being
repeated. But that is just his/her language and his/her situation. Only
after surveying a reasonable pool of experiences in other languages can one
make a more general (communal) conclusion that helping oneself is also
helping others.
While I completely understand your concern (I started a related thread(1)
some time ago about gender and variables) there is a big technical problem
here: if, for instance, the variable is used on an environment with several
"cases" (for example, the variable is accompanied by a verb that needs to
be declined on several genre and number cases), by eliminating the variable
and setting a new string for each case the work for the translators will be
heavily increased.
That said, maybe there are practical solutions to this kind of problems (I
do not have the technical background to even start thinking of them), but
for sure those solutions will not be easy to implement. I would love to see
this kind of problems solved, but IMO a lot of research is needed first.
Regards
Ricardo
(1) http://markmail.org/message/elhcwveyk4fh4i7w
Aivaras
2013.09.03 18:28, janI rašė:
On 3 September 2013 16:33, Aivaras Stepukonis <[email protected]>
wrote:
It is quite disheartening to find out that some menu item
titles/descriptors are used in several locations as one and the same
string
assuming that the linguistic expression in those locations can remain
unchanged (constant). Unfortunate, this is an English-centric assumption.
What has a constant linguistic form in English (thus allowing its
repetition across the UI without the need to adapt) may actually have a
variable linguistic form in another language (in my case, it's
Lithuanian).
Repeating such strings in the UI puts a local translator in a very
uncomfortable position because what looks correct in one place may turn
out
to have an incorrect grammatical form in another.
I've given an example of this in an earlier e-mail.
I agree with you, but I have heard others complaining about, why they
had
to translate the same word multiple times, e.g. you will find the string
"Cancel" more the 30 times.
rgds
jan I.
Aivaras
------------------------------****----------------------------**
--**---------
To unsubscribe, e-mail:
l10n-unsubscribe@openoffice.****apache.org<http://apache.org>
<l10n-unsubscribe@**openoffice.apache.org<[email protected]>
For additional commands, e-mail: [email protected].****org<
l10n-help@openoffice.**apache.org <[email protected]>>
------------------------------**------------------------------**---------
To unsubscribe, e-mail:
l10n-unsubscribe@openoffice.**apache.org<[email protected]>
For additional commands, e-mail:
[email protected].**org<[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
