From: verdy_p (verdy_p@wanadoo.fr)
Date: Wed Jul 22 2009 - 15:45:40 CDT
For such usage, applications are generally built to featuer two separate resources, which can be localized
separately: a short form and a long form. Some applications also offer an extended form where the term displayed
(for example in a selection list) can be explained once it is currently selected (or a mouse hovering event occurs,
where the application can display a tooltip, or in a separate area of the screen, out of the selection list, where a
longer text can be fit).
There is no rule abouthow to design your multiple resources, but if you build your applications so that length
restrictions will be needed to fit some interface, this should be explained to your translators. It's up to the
translators to choose the appropriate abbreviated forms in a way that can be both unambiguous and understandable by
users.
You should also provide to your translators a way to test their translations in your application, to see how it is
effectievly displayed (to avoid truncation of necessary information, or to avoid undesirable text superpositions)
Additionally, the way an abbreviation can be signaled to users (i.e. rendered) is locale-dependant. It is also very
often dependant of the application context which needs to define a coherent terminology. The level of coherence with
the rest of the system on which the application is run needs also investigation (you may need to adopt the
terminology already used in the backgfround OS running your application).
If you are designing a stand-alone device, make sure that this terminology is also adapted to your expected market
(we can see a lot of products "featuring" their own terminology, especially in their documentation or
characteristics, many of them being completely unexplained and not translated as well, specific to a brand, and this
is often considered very harmful for your consumers which absolutely don't know what it means or how these terms are
related to comparable features with which they are compatible. This is a situation very similar to the proliferation
of connectors on many devices, just designed to sell new cables that will be hard to find and very expensive. If you
want your product be really competitive, make sure you can effectively "connect" to your users and the product will
be immediately usable.
This cannot be safely made without performing tests or auditing your users with your product support pages. If you
don't have good translators for you, may be you can be helped by your users themselves that could help enhance your
translation and user interfaces: give them the tools to help you adapt your product to their languages, or bring
them to a user forum area where they will exchange their own information in their own languages. Listen them (don't
just hear your engineers and designers), you'll learn a lot more about how to localize your products and make them
more usable and with less defects (and correct your desastrous typos or strnage translations that are found in the
localized user interface of too many products).
In other words, there is NO standard defined for your request, the best yuo can do is effectively to build your
applciations with the final user as the target audience. Some audiences will really not like that you use
abbreviations everywhere (notably for languages where words are traditionally longer), and it will be even better to
use another term than abbreviating a longer one or a phrase.
I suggest you read resources about how to localize software applications before even trying to localize standalone
products (whose embedded firmware that can't be easily updated after sale and shipping). Localizing a product is an
art, not a technology built with standards full of misbehaving recommendations to follow blindly.
But all this is completely orthogonal to the encoding of texts with the Unicode standard (or with any other
encoding, including legacy 8-bit or MBCS codes). Unicode just encodes and standardizes characters and their own
properties, not their meaning within sequences or within specific languages or applications which are out of scope
of the standard (and that should really remain out of such scope).
> Message du 22/07/09 18:28
> De : "Alexander Kempgen"
> A : unicode@unicode.org
> Copie à :
> Objet : how to create automated meaning preserving abbreviations?
>
>
> Hi,
>
> I was wondering if there are format characters or other ways to mark
> parts of a word or words, that can automatically be shortened, if the
> text has to fit in a smaller space when displayed in a software
> application.
>
>
> Example:
> I'm currently working on the German localization of an iPhone
> application which can be used in portrait and landscape mode, the
> latter offering more horizontal space for longer single line strings
> in the gui.
>
> An example string for this is "Spitznamen-Kennwort" (nickname password).
>
> While this fits nicely in landscape, it does not fit in portrait mode
> and the system will automatically shorten it to "Spitznamen…", which
> leaves out important information.
>
> The abbreviation i would like to use in portrait is "Spitzn.-Kennw.".
>
>
> So my question is, is there a way to mark the long word like
> "Spitzn(amen/.)-Kennw(ort/.)" so the system will know where to shorten
> it in order to create a meaning preserving abbreviation? Or is this
> out of the scope of Unicode?
>
> Thanks,
> Alexander Kempgen
>
>
>
This archive was generated by hypermail 2.1.5 : Wed Jul 22 2009 - 15:48:37 CDT