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

List:       kde-i18n-doc
Subject:    Re: How to represent variable-length messages
From:       Nicolas Ternisien <nicolas.ternisien () gmail ! com>
Date:       2009-10-30 8:11:18
Message-ID: ccba71b50910300111n7af0401fk3365f435e2429589 () mail ! gmail ! com
[Download RAW message or body]

The real problem with messages separated with a <separator-char> is
that translations are not always used to be displayed on the screen,
and more particularly transmitted to a Qt widget directly (as a
'label' property for example), or can be modified before being
displayed.

If you give the ability to translators to magically add multiple
translations, it will probably have some strange behavior the original
developer didn't expect (like, displaying on the screen the entire "2
choices@2@2 choices done.")

The advantage of multiple messages is that the developer will have to
deliberately provide the way to translators to add multiple messages,
and if he did, he will expect such result without any bad surprise.


On Fri, Oct 30, 2009 at 8:18 AM, John Tapsell <johnflux@gmail.com> wrote:
> 2009/10/29 Martin Schlander <martin.schlander@gmail.com>:
> ..
>> I tend to go for "multiple messages" too.
>
>
> I urge people to reconsider their love the multiple messages approach.
>
> The tools need to just be fixed.  This is what Qt does - Qt Linguist
> supports multiple languages.
>
> Supporting multiple translations just needs to be done, and not hacked
> around, especially in a way that means that a translation can never
> have more translations.
>
> How you can think that there will never be a time where some
> translation will have more possible translations than in English?  And
> what if the programmer didn't think of multiple translations in the
> first place, but a translator wants to add multiple translations?
>
> John
>

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