Please - DON'T use long descriptive texts on buttons

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Sophie-2-2
Hi all,

Elizabeth Matthis wrote:

> Hi All,
> As I used to be the linguist who did all the German and English UI
> strings up till OOo 2.0 I would like to respond to this thread.
>
> You have my greatest sympathy, Andre! I know how difficult it is.
>
> On 01/19/09 23:58, Christoph Noack wrote:
> [...]
>>
>> Frank, you said in a previous mail that this is the first time such an
>> (big) issue has been raised. How were such problems handled by Sun or
>> StarDivision? Did you use only short button descriptions, did you have
>> far less languages to support, or was there a short "feedback loop" to
>> the developers to resize the buttons?
>>
>>  
> What we used to do was look into the translation (e.g. localization)
> database to find the longest word we could (in any language) and then
> we'd paint the button to be long enough to fit that many letters.

It might be the good old days :). Look at these issues :
http://www.openoffice.org/nonav/issues/showattachment.cgi/53248/zoom.jpg
http://www.openoffice.org/nonav/issues/showattachment.cgi/55284/char_formatting.png
http://www.openoffice.org/nonav/issues/showattachment.cgi/55285/pagestyle_textgrid.png
http://www.openoffice.org/nonav/issues/showattachment.cgi/55294/pdf_options.png

I have more of them but I think it's enough to show that even the design
of the dialog is not done perfectly any time.

> Usually it worked. If we were unlucky and some translation was indeed
> longer, then there were "feedback loops" to have the button redone by
> the developer. Sometimes issues/bugs were written because a new
> localization of OOo needed the button to be a different length and so
> the bug had to be fixed asap.

This has been true for several versions that the buttons were not large
enough, we even had a discussion about a button that behave like on the
phones screen, moving the sentence right to left then left to right
again ;-)
see this thread :
http://l10n.openoffice.org/servlets/ReadMsg?listName=dev&msgNo=9119

>> On the other hand, the discussion seems to make clear, how important the
>> careful design of such dialogs is. So I would like to remind to announce
>> specifications on the specifications-announce mailing list [1] to let us
>> have a look on it - together. If wording may seem to be ambiguous,
>> translation doesn't ease the problem ;-) (This reminder is also related
>> to me...)
>>
>>  
> Exactly, right, Christoph. The specs are the place for the button length
> to be set so the developer implements it right the first time. If
> languages commonly have longer wording than English, then it is
> important for people from those communities to be especially diligent in
> checking the specs and especially fast and clear in pointing out the
> need for more space. That is at least how I see it, because that is the
> handling I know from 3 years ago. I no longer work on UI strings, so I
> am not involved in the process these days. I doubt it has changed so
> much, though.

Yes you're right, but we need more resources in the l10n project because
we are already very short doing l10n, QA, etc. So I would like to see it
more as a global effort from all the teams involved.
>
> [...]
>> I really hope we will find a temporary solution for the next two minor
>> releases - until the right infrastructure is in place.

minor release do not have (normally) localization, so it's always an
issue for major releases only.
>>
>>  
> I wish OOo had a layout manager. I do not know when there might be one
> or how difficult it is to integrate. It must be very difficult or it
> would have been done long ago.

yes, it seems. In the mean time I hope we will find a solution to offer
better quality in our dialogs. A button that do not display the string
it should contain, but only the middle part of it is useless. The
buttons Andre mentioned will give :
[Actualiser les styles] for Updates Styles
[Conserver les anciens styles] for Keep old Styles. What the user will
see is somthing like [aliser les sty] or [rver les anc] which of course
means nothing.

Kind regards
Sophie


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Clément Pillias
In reply to this post by Elizabeth Matthis
Hi Liz and Sophie,

Le 20 janv. 09 à 19:29, Elizabeth Matthis a écrit :

>> I really hope we will find a temporary solution for the next two  
>> minor releases - until the right infrastructure is in place.
>
> I wish OOo had a layout manager. I do not know when there might be  
> one or how difficult it is to integrate. It must be very difficult  
> or it would have been done long ago.

A layout manager would not solve all the issues: if there is not  
enough room for the button row, there is not enough room. But it is  
true that a layout manager may help to have "nice degradation",  
meaning that the interface is worse but still usable. Unfortunately,  
this does not reduce the need to keep attention on text lengths.

Something is curious in Sophie's example screenshots: at some time,  
the text is truncated, but there would be enough space to display  
it.  E.g. the text "Tous les niveaux de repères de texte" in the  
screnshot [1].

So maybe we could reduce the number of issues by using coding  
principles such as "always set the field length to the maximal  
possible one." (Not already the case? curious). But this will not  
work for buttons.

Another solution, maybe simpler to increment than a layout manager,  
is Apple's solution: localization files can modify the text strings  
of an UI, but also some elements properties such as fields lengths  
and positions (actually, every user can change its interface this  
way). If the translation breaks the layout, it is still possible,  
then, to change the layout. This may bring more work to NL and QA, I  
don't know, since there could be more things to check. But on the  
other hand, solving issues may get simpler. And this is a solution  
more powerful than a layout manager alone (actually, different  
distributions could use different elements properties, e.g. to adapt  
a dialog to the product's logo size).

Regards,

Clément.

[1] http://www.openoffice.org/nonav/issues/showattachment.cgi/55294/ 
pdf_options.png
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Clément Pillias
In reply to this post by Sophie-2-2

Le 20 janv. 09 à 20:09, sophie a écrit :

> http://www.openoffice.org/nonav/issues/showattachment.cgi/53248/ 
> zoom.jpg

Since I use a french localized version, and since I have studied the  
zoom interface recently, I remember very well that on my Mac Os X  
version, the texts are not truncated.

By the look of the poor font anti-aliasing, I would say that the  
screenshot is from an X-Window port, and it seems to me that the font  
used is larger than on Mac OS X.

OK, all this to say that I just realized that the language is not the  
only source of length variations: the operating system is another one :(

Regards,

Clément.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Graham Perrin
Administrator
In reply to this post by Sophie-2-2
The KDE HIG and Microsoft guidelines previously offered seem fine. Apple HIG seem to lead to applications that are equally fine.

All four examples above have these things in common:

* implicitly or explicitly, multiple columns
* too many things in a single dialogue!

Often: less a problem with the text; more a problem with the overall approach to presentation.

---

Re: the fourth screen shot above, tab three of five, section four, we see: a heading, a separating line, radio buttons, two lines below the heading, two successive repetitions of the expression 'repères de texte', a menu that is absurdly wide for a single number '1', and wasted grey space above the unnecessarily wide menu.

A single line should suffice!

[Tous] niveaux de repères de texte visible

— lose the heading, lose the superfluous line, lose the radio buttons
— a menu, of pleasant width, comprises
   1, 2, 3, 4, 5, 6, 7, 8, 9, Tous
   and defaults to Tous.

(The 1—9 is a guess, I am completely unfamiliar with this particular dialogue, but you should get the gist.)

In that example I have probably broken a guideline or two, my point is not to be exact ;) rather, to encourage thinking about the ways that things are put together.

---

Without cross-posting to ui@ux, I suspect that concerns such as this may be well addressed as things progress in the Renaissance area.

Regards
Graham
Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Graham Perrin
Administrator
Many messages to digest, forgive me if I have missed a key point.

Most discussion in this topic assumes that

* all designs originate in English

followed by

* tasks of translation to French, German and other non-English language.

How often do designs originate, in whole or part, in non-English languages?

---

Changing the subject a little: the condensation of English in software dialogues is widely accepted but nonetheless, truly peculiar. The expression "Mind gap, mind gap, mind gap… " at a British railway station would look and sound unacceptably lazy, even rude; the familiar expression is "Mind the gap". But in a software setting (no-where else), users might *argue loudly* for the word "the" to be dropped!
Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Philip Ganchev
In reply to this post by Graham Perrin
If the labels fit inside the buttons, then it seems clear that using
non-descriptive button labels inreases the user's cognitive burden,
for the reasons Clement explained. I have this understanding from
reading articles about UX/UI/CHI and style guides, as well as my own
experience. This argument is easily settled with a reference to
relevant results. Unfortunately, I don't have any at hand. But Andre
said he was not arguing this in principle. He only wants to avoid
having translated strings that do not fit into the available space.

Andre wrote:

> Clément Pillias schreib
>> The translator should choose the best choice fitting in the >> allowed space. But if you only have a single text you have no >> choice, so this is maybe were a reinforced communication
>> between UX and NL could improve the process?
>
> Hmm .. this might cause some kind of "overcommunication".
> Waht really needs to be improved is the visibility of
> specifications. "Once upon a time" it was suggested to use
> [hidden email] to announce new specifications and updates > to specifications. This worked quite well for a handfull of specs.
> Even if the feedback was not so high in numbers, it was quite
> easy to review specification updates.

So if translators know about every new specification, they can do a
rough mental translation and tell the UX team if the strings are too
long. So why does [hidden email] not work anymore? Is it because new
specs are not announced by the UX team? Or because the mailing list
does not exist anymore? Or the sheer volume of new specs? Or some
other reason?

Or maybe translation needs to happen right after specs. Is that possible?

I find Graham's analysis insightful.  If translators have problems
with a dialog, they should let us know so we can redesign it. Maybe we
should examine all the dialogs in Renessaince.

But how should translators handle problematic translations for a
release? Here is one work-around that often works: shorten the labels
but keep the meaning and also keep most of the benefit of descriptive
labels.

Sophie wrote:
> [Actualiser les styles] for Updates Styles
> [Conserver les anciens styles] for Keep old Styles. What the user will
> see is somthing like [aliser les sty] or [rver les anc] ...

How about using "Actualizer" and "Conserver". I think this conveys the
meaning in this case. In German, it can be: "Aktualisieren" and
"Beibehalten", or "Aktualisieren" and "Alte Formatvorlagen".

Sometimes it is possible to shorten a phrase by making it slightly
ungrammatical. I'm not sure if these still convey the meaning to a
French speaker: In Sophie's examples:
[1]: "Adapter largeur et hauteur", or "Une page"
[2]: "Accentuation"
[3]: "Texte Ruby dessous/gauche du texte"
[4]: "Tous les niveaux"; "Niveaux visibles"

[1-4]
>> http://www.openoffice.org/nonav/issues/showattachment.cgi/53248/zoom.jpg
>> http://www.openoffice.org/nonav/issues/showattachment.cgi/55284/char_formatting.png
>> http://www.openoffice.org/nonav/issues/showattachment.cgi/55285/pagestyle_textgrid.png
>> http://www.openoffice.org/nonav/issues/showattachment.cgi/55294/pdf_options.png

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Sophie-2-2
In reply to this post by Clément Pillias
Hi Clément,
Clément Pillias wrote:
>
> Le 20 janv. 09 à 20:09, sophie a écrit :
>
>> http://www.openoffice.org/nonav/issues/showattachment.cgi/53248/zoom.jpg
>
> Since I use a french localized version, and since I have studied the
> zoom interface recently, I remember very well that on my Mac Os X
> version, the texts are not truncated.

This is a dev version of course you didn't see it in the final version,
this is kind of "my job" to not let a so poor quality version see the
day light.
>
> By the look of the poor font anti-aliasing, I would say that the
> screenshot is from an X-Window port, and it seems to me that the font
> used is larger than on Mac OS X.

I'm using linux, so all screen shots are under linux, but I don't care
the quality of the screen shot in fact.
>
> OK, all this to say that I just realized that the language is not the
> only source of length variations: the operating system is another one :(

I don't think so.

Kind regards
Sophie


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Sophie-2-2
In reply to this post by Philip Ganchev
Hi Philip, all
Philip Ganchev wrote:

> If the labels fit inside the buttons, then it seems clear that using
> non-descriptive button labels inreases the user's cognitive burden,
> for the reasons Clement explained. I have this understanding from
> reading articles about UX/UI/CHI and style guides, as well as my own
> experience. This argument is easily settled with a reference to
> relevant results. Unfortunately, I don't have any at hand. But Andre
> said he was not arguing this in principle. He only wants to avoid
> having translated strings that do not fit into the available space.
>
> Andre wrote:
>> Clément Pillias schreib
>>> The translator should choose the best choice fitting in the >> allowed space. But if you only have a single text you have no >> choice, so this is maybe were a reinforced communication
>>> between UX and NL could improve the process?
>> Hmm .. this might cause some kind of "overcommunication".
>> Waht really needs to be improved is the visibility of
>> specifications. "Once upon a time" it was suggested to use
>> [hidden email] to announce new specifications and updates > to specifications. This worked quite well for a handfull of specs.
>> Even if the feedback was not so high in numbers, it was quite
>> easy to review specification updates.
>
> So if translators know about every new specification, they can do a
> rough mental translation and tell the UX team if the strings are too
> long. So why does [hidden email] not work anymore? Is it because new
> specs are not announced by the UX team? Or because the mailing list
> does not exist anymore? Or the sheer volume of new specs? Or some
> other reason?

The reason is time and not enough resources, we are aware of new specs
on allfeatures@ list, but we need to read them, check where the
functionality is in the UI, understand how it works, etc.
>
> Or maybe translation needs to happen right after specs. Is that possible?

No, we have very short time for translation between feature freeze and
code freeze.
>
> I find Graham's analysis insightful.  If translators have problems
> with a dialog, they should let us know so we can redesign it. Maybe we
> should examine all the dialogs in Renessaince.

I think that the design should be thought in an international way and
not in english only language. But it's may be too difficult, I don't know.
>
> But how should translators handle problematic translations for a
> release? Here is one work-around that often works: shorten the labels
> but keep the meaning and also keep most of the benefit of descriptive
> labels.

We have to stay as near to the source language as possible, because
localization is done out of context and translators who contribute are
not the same every time.
>
> Sophie wrote:
>> [Actualiser les styles] for Updates Styles
>> [Conserver les anciens styles] for Keep old Styles. What the user will
>> see is somthing like [aliser les sty] or [rver les anc] ...
>
> How about using "Actualizer" and "Conserver". I think this conveys the
> meaning in this case. In German, it can be: "Aktualisieren" and
> "Beibehalten", or "Aktualisieren" and "Alte Formatvorlagen".

I think that the explanation should happen in the dialog and the button
are only there to say yes or no. I completely agree with Stefan on this
topic.
>
> Sometimes it is possible to shorten a phrase by making it slightly
> ungrammatical. I'm not sure if these still convey the meaning to a
> French speaker: In Sophie's examples:
> [1]: "Adapter largeur et hauteur", or "Une page"
> [2]: "Accentuation"
> [3]: "Texte Ruby dessous/gauche du texte"
> [4]: "Tous les niveaux"; "Niveaux visibles"

Sometimes languages are used as official language in countries where
this is not the mother language, this is the case for French but I'm
sure for several others too. So the meaning is really important and it
is conveyed by the semantics and the syntax, we have to care to both of
them and the more we respect them, the more the message the dialog has
to give is correct and with quality.

Kind regards
Sophie


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Clément Pillias
In reply to this post by Graham Perrin

Le 20 janv. 09 à 23:31, Graham Perrin a écrit :

> All four examples above have these things in common:
>
> * implicitly or explicitly, multiple columns
> * too many things in a single dialogue!
>
> Often: less a problem with the text; more a problem with the  
> overall approach to presentation.

Yes, making simpler dialogs is the job of the UX team, and it  
includes a simpler visual layout :) We have to do it to improve the  
user experience, but if it can reduce translation issues, it is a  
lucky side effect :)

> Re: the fourth screen shot above, tab three of five, section four,  
> we see: a heading, a separating line, radio buttons, two lines  
> below the heading, two successive repetitions of the expression  
> 'repères de texte', a menu that is absurdly wide for a single  
> number '1', and wasted grey space above the unnecessarily wide menu.
>
> A single line should suffice!
>
> [Tous] niveaux de repères de texte visible

"Afficher [tous les niveaux] de repères de texte" would be better.

Remind me this: http://worrydream.com/MagicInk/#p213

Unfortunately, your solution depends to much on english or french  
syntax. You may think to the plural form, inappropriate when the user  
selects the value "1." In some languages, "Afficher tous les niveaux  
de repères de texte" and "Afficher 3 niveaux de repères de texte" may  
use a totally different syntax, where the parts "tous" and "3" are  
not at the same position. But I don't know if OOo is translated in  
such languages :)

Sorry for all that french text ;)

Regards,

Clément.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Clément Pillias
In reply to this post by Philip Ganchev

Le 21 janv. 09 à 06:05, Philip Ganchev a écrit :

> I find Graham's analysis insightful.  If translators have problems
> with a dialog, they should let us know so we can redesign it.

+1 but this is exactly what André did (unfortunately he used a rather  
aggressive tone)

> Maybe we should examine all the dialogs in Renessaince.

+1 We should also create "guidelines" or "best practices" including  
benefits for translation.

> But how should translators handle problematic translations for a
> release? Here is one work-around that often works: shorten the  
> labels but keep the meaning and also keep most of the benefit of  
> descriptive labels.
>
> Sophie wrote:
>> [Actualiser les styles] for Updates Styles
>> [Conserver les anciens styles] for Keep old Styles. What the user  
>> will see is somthing like [aliser les sty] or [rver les anc] ...
>
> How about using "Actualizer" and "Conserver". I think this conveys  
> the meaning in this case. In German, it can be: "Aktualisieren" and  
> "Beibehalten", or "Aktualisieren" and "Alte Formatvorlagen".

Unfortunately this is not so simple. The dialog is about a template  
that has been modified, so a simple choice "keep/update" gives no  
indication about what will be kept/updated: this is not the template  
but the formating of the document.

Since the translators translate text without knowing the context,  
they could not see if the shortening of the text is coherent.

> Sometimes it is possible to shorten a phrase by making it slightly
> ungrammatical. I'm not sure if these still convey the meaning to a
> French speaker: In Sophie's examples:
> [1]: "Adapter largeur et hauteur", or "Une page"
> [2]: "Accentuation"
> [3]: "Texte Ruby dessous/gauche du texte"
> [4]: "Tous les niveaux"; "Niveaux visibles"

It conveys the meaning, but this would be really ugly.

Best regards,

Clément.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Elizabeth Matthis
Hi Everyone,

On 01/21/09 12:20, Clément Pillias wrote:
>
> Le 21 janv. 09 à 06:05, Philip Ganchev a écrit :
>
>> I find Graham's analysis insightful.  If translators have problems
>> with a dialog, they should let us know so we can redesign it.
>
> +1 but this is exactly what André did (unfortunately he used a rather
> aggressive tone)
>
I agree that the UX team should help redesign to fix such issues.
Definitely, an issue should be sent directly to the spec author (who
should get UX help) or the engineer implementing it, depending on the
scope of the change needed (Spec author if a redesign/rewrite is
necessary, Engineer if button is long enough but text is cut off for no
reason or something else small and not specified in spec)
>> Maybe we should examine all the dialogs in Renessaince.
>
> +1 We should also create "guidelines" or "best practices" including
> benefits for translation.
>
I already wrote guidelines that included this and many other aspects for
anyone writing the source language (i.e. designing new dialogs, etc.).
http://specs.openoffice.org/collaterals/guides/text-style-guide.html

There are a few words or links that need to be updated (e.g. mentions of
Sun internal tooling) but in general nothing has changed. We could move
them to the wiki to update and elaborate them if it is of interest to
any of you. However, I think the main problem is not lack of guidelines,
but rather a disregard for following them or ignorance of their
existence. (Please forward the link to my guidelines to anyone and
everyone who might benefit from them. Thanks!)

Quotation from the guidelines:
http://specs.openoffice.org/collaterals/guides/text-style-guide.html#Aware


    Be Aware of Text Length

English text is much shorter than most of the localizations which
correspond to it. In fact, the localized text can be three times as
long. As a rule of thumb, check the Brazilian Portuguese translation (by
searching in LingTool) to see how many characters and spaces will have
to be visible on the button or in the space of the dialog. Sometimes,
however, Italian or French can present the longest translation. In
OpenOffice.org languages, Finnish seems to do a good job of competing
with Brazilian Portuguese for longest text. In the end, quality testing
of localized builds is the only way to find any imperfect UI text that
would call for a spatial adjustment in the design, so just do your best.

Until OpenOffice.org gets a layout manager which would automatically
adjust the space needed to accommodate the text in different languages,
the UI designer must leave enough room on the screen to allow space for
the longest translation. That is also why most of the text is positioned
above a control, such as a text box, or after a control, such as a check
box.

...........

By "check the [...] translation" I mean, to see the word or a similar
text where it is already used in the software (and therefore already
localized)

Instead of "LingTool" (the StarOffice localization database that I used
to use) I suggest looking at the localizations in the source code, or in
"pootle" (the tool known in the localization community, which will be
made available for even more languages soon----I spoke with Rafaella
Braconi about it just now)

[...]
As someone who worked for several years translating StarOffice from
German to English, I know there are basic translation principles that
have to be followed and do not allow for ad hoc decisions for each text
string.: The same translation should be used every time, never synonyms;
correct grammar, international word choice (no regionalisms), etc.

Sophie is an expert in this area and really knows all the tips and
tricks as well as what you can or cannot do.

There are enough things to think about in the target language without
trying to compensate for poor design or bad strings in the source
language. I am going to post a note to this effect on the dev list.
There are many new OOo developers (since the very loud UI Linguist left
3 1/2 yrs ago) who ought to be reminded of l10n needs and the UI text
guidelines. ;-)

Best regards,
Liz

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Graham Perrin
Administrator
Clément Pillias wrote
Sorry for all that french text ;)
Thank you for correcting my French text ;)

(I remain unfamiliar with that particular dialogue, one day maybe I will stumble across it.) 

Elizabeth Matthis wrote
… I already wrote guidelines that included this and many other aspects for anyone writing the source language (i.e. designing new dialogs, etc.).
http://specs.openoffice.org/collaterals/guides/text-style-guide.html

… Quotation from the guidelines:
http://specs.openoffice.org/collaterals/guides/text-style-guide.html#Aware

    Be Aware of Text Length

… There are enough things to think about in the target language without trying to compensate for poor design or bad strings in the source language. I am going to post a note to this effect on the dev list. There are many new OOo developers (since the very loud UI Linguist left 3 1/2 yrs ago) who ought to be reminded of l10n needs and the UI text guidelines. ;-)

Best regards,
Liz
Many thanks to Liz for past/present guidelines, and for actions towards improvement.
Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Clément Pillias
In reply to this post by Elizabeth Matthis
Hi Elizabeth,

Le 23 janv. 09 à 09:57, Elizabeth Matthis a écrit :

> On 01/21/09 12:20, Clément Pillias wrote:
>>
>> Le 21 janv. 09 à 06:05, Philip Ganchev a écrit :
>>
>>> I find Graham's analysis insightful.  If translators have  
>>> problems with a dialog, they should let us know so we can  
>>> redesign it.
>>
>> +1 but this is exactly what André did (unfortunately he used a  
>> rather aggressive tone)

> I agree that the UX team should help redesign to fix such issues.  
> Definitely, an issue should be sent directly to the spec author  
> (who should get UX help) or the engineer implementing it, depending  
> on the scope of the change needed (Spec author if a redesign/
> rewrite is necessary, Engineer if button is long enough but text is  
> cut off for no reason or something else small and not specified in  
> spec)

I am not sure to agree with this "procedure". It would certainly  
decrease the time needed to solve an issue, and increase the number  
of issues solved, but in the same time it can reduce the quality of  
the solution, because a single person has always the tendency to  
solve an issue in its own way, which is often quite different from a  
community-based solution.


>>> Maybe we should examine all the dialogs in Renessaince.
>>
>> +1 We should also create "guidelines" or "best practices"  
>> including benefits for translation.
>>
> I already wrote guidelines that included this and many other  
> aspects for anyone writing the source language [...]

Yes, I am aware of that excellent work. But this is a long text, and  
it is likely that only people concerned with translation or writing  
will read it. My idea was rather to have guidelines for every kind of  
interface element (buttons, dialogs, toolbars, etc.) mentioning  
translation issues.

For example we could have a "dialog guideline", telling that in modal  
dialogs, buttons should be labeled with action verbs such as "delete"  
or "save" rather than generic terms such as "OK", "yes" or "no" -  
this is what most Humane Interface Guidelines does. But we could also  
add that the label should use a single word if possible and never  
more than three, because more words can lead to grammatical issues  
during translation, and because translated text can get up to three  
time longer than the original.

These dedicated guidelines may have more chances to reach the  
developers and UX team members :) And they can be more precise. And  
since these guidelines are rather dedicated to developers, we could  
also link to guidelines or FAQs for translators such as "You have  
difficulties to translate a dialog?", telling what can be done, who  
should be contacted, how and when to fill an issue, etc.

Best Regards,

Clément.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

André Schnabel
Hi,

Clément Pillias schrieb:
>
> For example we could have a "dialog guideline", telling that in modal
> dialogs, buttons should be labeled with action verbs such as "delete"
> or "save" rather than generic terms such as "OK", "yes" or "no" - this
> is what most Humane Interface Guidelines does. But we could also add
> that the label should use a single word if possible and never more
> than three, because more words can lead to grammatical issues during
> translation, and because translated text can get up to three time
> longer than the original.

If you are going to write this (or at least when it is almost done) -
please send a mail to dev@l10n (or dev@native-lang) or a least a mail to
this list and ask translators for review.  I'll try to give input froma
translators point of view (If I fail to do so, I'll never come back and
blame the UX team again.)

>
> These dedicated guidelines may have more chances to reach the
> developers and UX team members :) And they can be more precise. And
> since these guidelines are rather dedicated to developers, we could
> also link to guidelines or FAQs for translators such as "You have
> difficulties to translate a dialog?", telling what can be done, who
> should be contacted, how and when to fill an issue, etc.

Would be very helpfull.
Still the problem for translation issues is, that they are visible only
very late in the release cycle.

André

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Clément Pillias
Hello,

Le 23 janv. 09 à 19:37, André Schnabel a écrit :

> If you are going to write this (or at least when it is almost done)  
> - please send a mail to dev@l10n (or dev@native-lang) or a least a  
> mail to this list and ask translators for review.  I'll try to give  
> input froma translators point of view (If I fail to do so, I'll  
> never come back and blame the UX team again.)

OK, I think I will try to do something like this. But I need to think  
about it a little more… I will keep you informed.

> Still the problem for translation issues is, that they are visible  
> only very late in the release cycle.

Yes. I still don't have a clear vision of the translation process, so  
maybe I should participate in french translation to better understand  
it.

Regards,

Clément.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Please - DON'T use long descriptive texts on buttons

Graham Perrin
Administrator
In reply to this post by Sophie-2-2
sophie-2 wrote
I think that the explanation should happen in the dialog and the button are only there to say yes or no.
-0.5

Buttons should be more descriptive than

        yes
        no

* For each button, somewhere in the dialogue: the explanatory text. Concise and gramatically correct. (If concise is impossible, then back to the drawing board: consider why the thing is over-complicated.)

* The word on the button should complement or marry a word in its explanatory text.

* If more than one word is required on the button: keep the expression very concise. Follow OS guidelines and OOo guidelines. (If concise is impossible, then back to the drawing board.)

I think that the design should be thought in an international way and not in english only language. But it's may be too difficult, I don't know.
+1

With a good software development environment, not difficult.

Discussion in this topic suggests to me that a good layout manager should be a cornerstone to design, development and translation activities — some of which may occur in parallel.

… time and not enough resources, we are aware of new specs on allfeatures@ list, but we need to read them, check where the functionality is in the UI, understand how it works …

… very short time for translation between feature freeze and code freeze.
Suggestion: designers, developers and translators (some overlap between these groups) should (a) identify a co-ordinating person/group then (b) request greater time and (c) request resources to ease the collaboration.

Resources may be:

  i) suitable software development environment(s)

 ii) some thing that plugs in to, extends, or represents EIS in a way that improves collaboration

iii) et cetera, not for me to guess or decide :)

Regards
Graham
12