[TFUI] Re: Locale independence and grammatical structure

qazsedcft wrote:

> I am posting here since I don't know of a more specific group. If you
> know of one feel free to redirect me.

A newsgroup that covers your platform will know how to connect the esthetics
of localization to the techniques.

> I would like to know how to deal with grammatical structure in a
> locale-independent program. For example, suppose that we have a
> user-entered field called "nationality" which may be used in several
> different contexts. We may want to use the nationality as a noun or an
> adjective, or use it possessively, or distinguish by gender and number,
> etc. In English it is fairly simple to plug the name in and add an s or
> 's or a few articles. However, in languages with inflections it's quite
> a bit more complicated.
>
> Making a huge dictionary of all words in all possible contexts may
> quickly become unmanageable when translating to several languages,
> especially in software that is highly customizable.

Why is your software highly customizable? Is this a real need or an expected
need?

What would happen if you pre-localize every complete string you'l need?

Let me think of a simple reason you have this problem. Given a table with
columns "name address city state zip", you now need a locale table. For
Sanskrit, you need (roughly) "naama viithi graaman deshe sa'nhitaa". (You
will also need the Devenagari character set, most likely in UNICODE, via
UTF-8 or -16, but we'l get back to that.)

If the user forgets to enter their name, your status bar must prompt with
"please enter a name". To localize, you now need "please enter a %s", and
you will sprintf() that with the missing field from the local table's entry
corresponding to the data table's column. Switching to Spanish, we get
"incorpore por favor su nombre".

Now we approach the problem you cite. If an English-speaking user forgets
their address, they need to see "please enter an address". However, a blind
substitution from our tables yields "please enter a address".

Poor grammar offends educated users. (French people might possibly be the
exception here;) Further, we have no idea how many kinds of grammar nuances
all the different target languages may expose. Sanskrit varies nouns based
on their occupation within a phrase.

The first defense, as in all programming, is encapsulation. The string
"Please enter the \"%s\" field" might be easier to localize, if a language
permits less grammar strictures to cross quotation boundaries. (And note
that grammar strictures cross parenthesis if the result would sound odd when
spoken aloud.)

The next defense, again, is to pre-localize complete strings in preference
to writing an entire grammar generator yourself. Maybe our locale table
should redundantly provide "please enter your name", "please enter your
address", etc.

The last internal defense is to bypass sprintf(), and to expand strings
using a custom function which expands numbered arguments. If we wrote such
Format() function, then Format("the %2 brown %3 jumped over the %1 dog",
"lazy", "quick", "fox") returns "the quick brown fox jumped over the lazy
dog". This allows you to vary word order between languages with different
places for their parts of speech.

Yes, there's a tribe in Brazil whose language goes strictly "object verb
subject", so "the man bit the dog" wouldn't sound unusual to them.

Now we come to the external defenses. Whatever you write, your linguists
must read the results. They should drive your program, to see if it offends
them, and you should also give them this system:

    http://www.c2.com/cgi/wiki?BroadbandFeedback

Instrument your acceptance tests to take pictures of each window, and each
formatted message box in your system. (You do /have/ automated tests, don't
you?) Configure these tests to run once per locale, and to upload the
resulting pictures to a web site, such as a Wiki. Then instruct your
linguists to browse this site and review each page.

-- 
  Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces






To unsubscribe, email:
TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org
 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/TestFirstUserInterfaces/

<*> To unsubscribe from this group, send an email to:
    TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/