[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: KDE4
From:       Chusslove Illich <caslav.ilic () gmx ! net>
Date:       2005-04-14 7:29:55
Message-ID: 200504140929.58582.caslav.ilic () gmx ! net
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


>> [: Chusslove Illich :]
>> For solving the splitting problem, back than Reinhold Kainhofer
>> proposed [...]
>
> [: Hasso Tepper :]
> Yes. Main issue isn't solved yet though - who will implement this
> parsing and modifying layout? :)

Ah, damn, I am constantly trying to avoid learning anything about GUI 
programming, but sometimes I wonder if, perhaps, I should abandon this 
policy :)

>> [: Chusslove Illich :]
>> The solution is: if, instead of just translating msgid, arguments to
>> placeholders themselves could be *transformed at runtime*, you could
>> make them into the form you need.
>
> [: Hasso Tepper :]
> It's not the main problem. These strings are taken from *.desktop
> file - that's the real problem. There is no way to change this in
> GUI [...]

Well, I cannot claim 100% that .desktop files are actually *within full 
reach* of scripting system, but take this example (attached image). It 
shows the Location menu of Konqueror, with all of its "Open with" entries 
properly processed for Serbian language (correct case of noun). Now, where 
do the application names in this context come from?

The blue frame is for Mozilla Firefox -- originally it was displayed in 
English, so I don't really know where it came from. The red one is for 
Gimp Image Editor, and it was originally shown in Serbian translation, but 
with wrong noun form; am I right to think that it came from a .desktop 
file translated by some of our Gnome translators (we in KDE surely didn't 
do it)?

As an example of what can possibly be lacking in the application code, but 
is very easy to fix to support the scripting system, look at the green 
frame. It is the application name in window title, and as you can see, 
also properly transliterated. In the original code 
(kdelibs/kdecore/kapplication.cpp), this string was added to window title 
like this:

s += QString::fromUtf8(" - ") + caption();

I changed it to:

s +=   QString::fromUtf8(" - ")
     + i18n("Application name in window title", "%1").arg(caption());

Resulting with this entry in kdelibs.po:

msgid ""
"_: Application name in window title\n"
"%1"

and the scripted solution:

msgstr "%1"
"|/|(lambda (app) (application-nominative app))"

Am I right to assume that entries from .desktop files come into GUI in a 
similar way, and that therefore if the supporting i18n call is missing, it 
could be added in a similar way to this example (pure "%1" with context 
info)?

> Yes, I see that you have (scripting) solution as well, but ... it's
> very complicated to use for translators of third-party applications.
> Ie. in your example (apps.scm) I (as coordinator of Estonian team)
> have to take care of adding entries to the apps.scm for every
> translated third party application.

I don't think that you should keep track of translated apps, but rather 
track of *any* apps usable in a given context, and having ready forms for 
them. So, the only unresolved problem is how to collect comprehensive list 
of such apps (say, thousand or so of them would be 99% of what can appear 
in prominent GUI strings, like "Open with %1").

I am also tweaking a form-generating system which would allow fast addition 
of new apps (though, how fast depends on a language), something from which 
the scripting code could be automatically generated. This is the current 
example, for several browsers:

Mozilla: ж: Мозил|а, Мозил|ин;
Firefox: м: Фајерфокс|, Фајерфокс|ов;
Galeon: ж: Галиј|а, Галиј|ин;
Konqueror: м: Конкерор|, Конкерор|ов;
Opera: ж: Опер|а, Опер|ин;

The parts behind bars (|) are form generators (nicely coinciding with noun 
endings) for different classes of nouns. Each of these lines generates 7 
noun forms, and 7 case * 4 gender * 2 number = 56 possessive adjective 
forms (for constructs of type "%1's settings", where %1 is the app name). 
Using this system, I can "translate", say 30-60 app names in an hour -- 
somewhat faster than the apps get written, isn't it? :)

Also, don't forget, this transformation of app names is only one of the 
things the scripting system could be frequently used for. So if it still 
seems unfeasible, there are other applications of scripting.

> 0.1 seconds is quite much in the sense of GUI speed.

Really? I think I've seen somewhere that for user interaction, response 
below 0.2 seconds is acceptable (ok, except in FPS game :) But anyway, my 
estimate was grossly exaggerated: menu with *100* entries, *all scripted* 
using *the slowest script* I came up with (and not to forget, the 
scripting system delivered 6 times this, on a not too fast machine by 
*today's* standards).

> Although quite nice solution, I think that most of context problems can
> be solved in application level. We should kick developers [...]

Remember the examples of fuzzy clock and KWeather. No matter what one did, 
it either left some language without solution (fuzzy clock), or requested 
enormous multiplication of messages (and many of them illogical) even for 
languages which didn't need them (KWeather). Scripting, on the other hand, 
would enable translators not to pester developers about their own language 
specific problems, and developers not to introduce a "fix" in the code, 
which might hurt some other language.

-- 
Chusslove Illich (Часлав Илић)
Serbian KDE translation team

["ktd02ma.png" (image/png)]
[Attachment #6 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]