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

List:       kde-i18n-doc
Subject:    Re: KDE4
From:       Hasso Tepper <hasso () kde ! org>
Date:       2005-04-14 5:30:13
Message-ID: 200504140830.13347.hasso () kde ! org
[Download RAW message or body]

Chusslove Illich wrote:
> > [: Hasso Tepper :]
> > * Widgets as part of translatable string.
> >
> > Perfect example is recurrence rules in Korganizer.
> > http://lists.kde.org/?l=kde-pim&m=108816679303643&w=2
>
> I remember this one. There are actually two problems there. One is that
> the logical sentence formed by the combination of widgets and text is
> hoplessly split from the translator's viewpoint, and the other is context
> dependence of widgets' contents (like "on January", "of January", where
> cases of "January" might be different).

Exactly.

> For solving the splitting problem, back than Reinhold Kainhofer proposed
> something like this: Programmer supplies a msgid with placeholders of the
> form
>
> "&Repeat on [nthweekday] [weekday] in [month]"
>
> and translator does this
>
> "&Wiederholt am [nthweekday] [weekday] im [month]"
>
> Afterwards, the program parses the translated string to get the ordering
> of text and widgets correct. Reinhold also specifies some modifiers to the 
> placeholders, to be able to control the other problem, context dependence.

Yes. Main issue isn't solved yet though - who will implement this parsing 
and modifying layout? :)

> I would modify this slightly. First, replace placeholder text with normal
> placeholders, so that msgid is "&Repeat on [%1] [%2] in [%3]", and
> communicate placeholder meanings through context info (thus making it
> more familiar to translators, and avoiding the possibility that
> placeholders get mistakenly translated). Secondly, that means I drop
> control of context dependence suggested by Reinhold, leaving it to be
> solved separately.
>
> To be able to effectively tackle context dependence (and for aestetic
> reasons?) I think that the actual sentence in the dialog should not be
> "littered" with visible widgets, instead changeable words could be
> highlighted in some way, and when clicked upon bring up a widget in
> place. Maybe this could be generalized by implementing a sort of higher
> level, "sentence control" widget?

Sure. I don't think that this one particular place is the only one with 
issue. Main issue (who will implement it) remains though.

> > The way to handle strings from *.desktop files in context.
> >
> > Situation regarding this is especially bad after introducing
> > "Show/hide" configuration menuitems instead of checkbox menuitems.
> > "%1" must be in different form in "Show %1" and "Hide %1".
>
> This is the same as second problem above, same English form needs
> different translated forms in different context. 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.

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, there is no 
place in *.desktop to write transformation rules etc. The solution might be 
to define additional keys. For example X-KDE-ShowName, X-KDE-HideName, 
X-KDE-OpenWithName, X-KDE-AboutName (argh, there are too many of them :( ). 
This adds bloat to the desktop files of course and isn't really needed for 
many of them. Maybe something in the scripty level? Ie. for msgid 
"Name=Konqueror" translator _can_ add to the msgstr other names and scripty 
will take care of the rest?

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.

> > Sidebar of configuration dialog becomes too wide with longer texts.
> > There is (not very widely known) solution - you can insert "\n" into
> > translation. But that doesn't help if strings are coming from *.desktop
> > file (like Konqueror and desktop configuration dialogs etc.). But maybe
> > text should be automatically wrapped in sidebar (like sidebar in Juk
> > does)?
>
> I think that whenever possible, formating issues should be lifted of the
> translators. In this concrete case, one should decide whether that text
> in sidebar should (like for desktop icons) or should not (like on
> buttons) be wrapped, and then apply the same rule to any text it gets,
> original or translated. I.e. I don't think it is a translation issue.

Agreed. Should file bugreport probably. And it would be awesome to have 
support for soft hyphens in this context. Just dreaming ... sorry ;). AFAIK 
Konqueror doesn't support soft hyphens either (bug #33855).

> > More thoughts?
>
> Scripted translations, the solution to the problem of context dependency
> of translated forms. I have already been talking and writing about this
> (http://caslav.gmxhome.de/writings/ktranscript.html), and these days I
> have been polishing the system and testing its performance (last time,
> Stephan expressed his concerns about performance of scripting-enabled
> KDE).
>
> Concrete test setting and numbers will follow, but consider this: a tight
> loop, executing *nothing but an i18n call*, is only about 2 times slower
> when message is not scripted, and 2-7 times slower for reasonable scripts
> (those expected to be most frequently needed).
>
> In absolute terms, AthlonXP 2000 (1.67 GHz) machine was able to pull 6
> Kmsg/s (thousand messages per second) for the above worst case of 7 times
> slower than non-scripted KDE, and in GUI you need about 1 Kmsg/s (number
> comes from this condition: for a context menu with 100 entries allow no
> more than 0.1 second for obtaining translations of entries).

0.1 seconds is quite much in the sense of GUI speed. Although quite nice 
solution, I think that most of context problems can be solved in 
application level. We should kick developers (OK, for apps in KDE CVS I go 
and fix these myself ;). But if strings that should be changed according to 
context are coming from desktop file, I can do nothing at the moment. This 
is the case scripting would save my day, but ... maybe it's just overkill 
for this particular case?


with my best wishes,

-- 
Hasso Tepper
KDE Estonian Team
[prev in list] [next in list] [prev in thread] [next in thread]