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

List:       kde-i18n-doc
Subject:    Re: color kcm translation (was: [KDE Usability] Description of
From:       "Yuri Chornoivan" <yurchor () ukr ! net>
Date:       2009-08-25 17:48:32
Message-ID: op.uy8bq5iyl2zvei () mycomp
[Download RAW message or body]

Hi!

На Tue, 25 Aug 2009 02:30:27 +0300, Matthew Woehlke  
<mw_triad@users.sourceforge.net> написав:

> Albert Astals Cid wrote:
>> A Dilluns, 24 d'agost de 2009, Matthew Woehlke va escriure:
>>> Maciej Pilichowski wrote:
>>>> On Monday 24 August 2009 21:13:15 Albert Astals Cid wrote:
>>>>> Of course that's possible, but why one would want to make a more
>>>>> incomplete/imprecise translation?
>>>> Because it does not fit the screen. But I think that it is better to
>>>> decide up to translator -- she/he knows the language after all and
>>>> such tips may do more harm than good.
>>>>
>>>> Besides, in such case, I would opt to wait and see if this is really
>>>> problem (i.e. if translators need such tips).
>>> They do. Which reminds me, I'd like to commit the attached and edit
>>> various i18n comments/extracomments to point at it.
>>>
>>> Basically this is a guide for translators how to translate text in the
>>> color kcm for best usability, for elements where the text itself isn't
>>> necessarily as important as how many characters long the translations
>>> are. It covers rationale as well as suggestions for several areas of
>>> translation.
>>>
>>> Any thoughts? Is this sort of thing acceptable, and if not, anyone have
>>> any better ideas?
>>  Seems a possible solution for those teams that are careful (some are  
>> not mind you).
>>  In the ideal world we would not need that but if you have ruled out  
>> any other possible solution like a different layouting (i'm getting  
>> tedious i know) i think you could commit it to trunk and to branch  
>> AFTER 4.3.1 is tagged.
>
> Well since you mentioned it again, I can talk about it here rather than  
> the other thread. My stance is... well, outlined in the document  
> attached to the previous message :-).
>
> I don't want translation concerns to dictate the layout. Indeed, I don't  
> want the /text/ to dictate the layout, as you can plainly tell from the  
> generic preview that uses single letters for just about everything :-).  
> (And further, the bits about *minimum* length are important; one of the  
> reasons for the set preview is that it's hard to get a good feel for a  
> color from a preview string that is one character long.) IMO it's better  
> to have inadequate text (generic preview, case in point!) to keep the  
> preview small; especially as it already nibbles away at the size  
> available for other, important controls.
>
> At the very least, adding the i18n of " text" as is done IIRC in the  
> translations demonstrated in the previously mentioned bug is just  
> gratuitous and unneeded :-).
>
> It's not a problem if there is imperfect adoption; that just means we  
> have a basis for requesting different translations (politely, of course  
> ;-) ).
>
> That said, if there are no objections, am I on the right track with the  
> best way to communicate this with the translation teams?
>

Just one question:
I am an Opera web-browser translator. Opera programmers and QA department  
try to comment messages with limited sizes by the statements like this:

Note to translators: the translation should not be longer than the English  
string, at most 1 or 2 additional characters.

(Mobile browsers have even higher layout restrictions than KDE :))

I know, it is hard for KDE developers to add such a comment (GNOME/Gtk  
developers seems never even thought about this AFAIK (I am also a  
translator of some Gtk programs)). But if you really need to keep layout  
clean maybe it will be better not using letters at all (just icons). It  
will significantly increase usability and lower threshold for users. :)

Thanks,
Yuri

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

Configure | About | News | Add a list | Sponsored by KoreLogic