2013.09.03 23:24, Regina Henschel rašė:
Hi Aivaras,
Aivaras Stepukonis schrieb:
2013.09.03 19:36, Regina Henschel rašė:
Hi Aivaras,
Aivaras Stepukonis schrieb:
The expression "+oswmg||Formula" occurs both in
Writer > View > Toolbars > Formula
and
Writer > Table > Formula.
The commands are identical. Both are command '.uno:InsertFormula'. The
string is bound to the command and therefore the string is the same.
I am not a programmer and therefore cannot comment on the program's
inner technical workings and limitations.
It describes the current design. It does not mean, that it has to be
this way forever.
In Lithuanian, I need to use two different grammatical endings for
these
two instances and, of cause, I cannot accomplish this because it is
one
and the same string.
What is the reason, why do you need two different strings? It is in
both cases a simple menu item.
As an object it may be one and the same, but it is being address through
a language that may in fact pay attention to the shifting environment in
which that object is being addressed.
Context 1: Writer > View > Toolbars > Formula. Proper Lithuanian
translation would be this: Rodyti > Priemonių juostas ("-as" =
accusative) > Sprendinio ("-io" = genitive). "Sprendinio" is in the
genitive case because it refers back to "Priemonių juostas", meaning
something like "[Toolbar] of/for Formula", the part in brackets being
assumed.
The main thing to learn from this is that, in Lithuanian, there is a
grammatical connection between "View", "Toolbars" (which are viewed),
and "Formula" (which is an attributive adjective for a "toolbar").
That is interesting. I would have never seen it that way. We in German
interpret the items more like separate headings.
If needed we can easily combine words. In this special case we could
use 'Rechenleiste' (Google translates this to 'formulė Baras' in
Lithuanian), and we indeed use 'Rechenleiste' in the extended tip.
There are ways to work around the situation in Lithuanian, too, but they
are what they are - workarounds. And the linguistic outcome of such
workarounds is a general impression of unnaturalness and artificiality
in the Lithuanian translation that is alienating for the end user. It
may be so because the Lithuanian language requires a greater degree of
interconnectedness than some other languages. German might be more
tolerant in this respect and closer to English (which is a Germanic
language, after all).
And that Google translation... You know what it means? Well, it's a
"formula pub"! Not that driving a formula 1 car to a local pub to get a
drink may not involve a math formula of sorts...
Context 2: Writer > Table > Formula. In this particular instance,
"Formula" should be translated by "Sprendinys" ("-ys" = nominative)
because it is preceded by a noun requiring no grammatical adjustment.
As a result, context 1 needs the genitive case, context 2 the nominative
case. A word in the nominative case when it should have been in the
genitive looks like a mistake. I am very uncomfortable with this state
of affairs...
I understand your dilemma. What to do? You should at least document in
Bugzilla, that there is a problem, and that there is something needed
like a conditional translation.
I'll do this some time after September 6th.
In the future, I would be nice two have two strings instead of one.
I see no way to provide different strings, because the context is the
same, in both cases 'swriter'.
Contexts are make up of sub-contexts and it is the latter, not the
former, that may be the determining factor in deciding why a certain
ending, tense, case, gender, number, you name it!, is the proper
translation of a short phrase.
If there is no technical means to accommodate languages in UI without
crippling them (to a lesser or greater degree), than, oh well, there is
none. My intention is to bring this issue up for constructive discussion
as well as to contribute our general awareness of the cultural
differences that are there in the world for real.
That request is reasonable. It is important that we listen to each
other and try to understand the problems of others. Therefore my asking.
Kind regards
Regina
---------------------------------------------------------------------
To unsubscribe, e-mail: l10n-unsubscr...@openoffice.apache.org
For additional commands, e-mail: l10n-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: l10n-unsubscr...@openoffice.apache.org
For additional commands, e-mail: l10n-h...@openoffice.apache.org
