I have implemented a multi-language interface in my framework as well.
I have seen several approaches to multi-language so far, in various
tools, but somehow most of them missed a very important point.
Unfortunatelly that point is very easy to miss if you're a native
English speaker. Namely, the genders, the articulated form and the
concatenation of strings. I will come back to this later. Dictionary
tables comes first:
As you surely know, each language has a code page. Problem is the DBF
file can have one single code page, so technically it's impossible to
store chinese text and german text in a single DBF. One of them would
go nutty.
Second, some languages use single-byte character sets (such as
English), others use double-byte character sets. In order to unify
these character sets, Unicode was invented, but sadly, Visual FoxPro
doesn't know how to use that. So you have to keep in mind that if the
language you are translating to is a double-byte character set
language, all your texts will be double in size for same text length.
I personally used the separate dictionary table per language approach.
The language names, charset and RTL are stored in a table, and each
record of this table has a corresponding dictionary table on disk.
When user wants to create a new translation, I just add a record in
languages table and create the corresponding dictionary table, which
is a copy of English table.
Phew. I hope that makes sense.
Now the grammar.
Rule no 1. NEVER EVER assume anything.
For example, in English this is perfectly functional: "Create new
<<lcObject>>", where lcObject can be "table", "trigger", "database" or
whatever. I've seen applications built that way. Problem is this
approach doesn't work in all other languages. They may be some, but
definately not all. The most famous are the romance family languages
(Italian, French, Spanish, Romanian). There are two distinct problems:
1. These languages have genders for nouns. And guess what, there are
three genders. Masculine, Feminine and Neutral. Difference is subtle
and I won't get this way in this message. You just keep in mind that
"database" and "trigger" behave differently from each other.
2. The word order is different. English is famous for putting the
adjective before the noun. Guess what, other languages don't work that
way.
A quick example:
English: Romanian
Spanish
Create new table Creare tabelă noua
Crear la nueva tabla
Create new trigger Creare declanşator nou
Crear nuevo desencadenador
Spot the differences? "new" has same form in english, but different
forms in other languages, and that form depends on the word after it.
Also the words order is different. By chance, Spanish has same order
as english in the above example, but you can't assume this is true for
every phrase in every language.
3. The definite/doubtful article. These would be "the" and "a / an" in
English. Both of them are placed before the noun. Same goes for french
and spanish. But not for Romanian or Swedish, which alter the actual
word. Example:
English French
Romanian
Masculine gender: Tree Arbre Copac
The tree L'arbre
Copacul
A tree Un arbre
Un copac
Feminine gender Flower Fleur Floare
The flower La fleur
Floarea
A flower Une fleur
O floare
Confusing, isn't it? And not to mention that I don't speak chinese or
arabic and God knows what rules they have over there.
4. Actual translation. English is one of the most concise languages in
the world. If you plan multilanguage thinking in English only, you're
asking for troubles. Let me dig an example. Let's say "Cancel". In
Spanish you can translate Cancel to different words, depending on
context. If you're breaking an ongoing operation (such as copying a
file), the translation would be "Cancelar". But if you're putting the
cancel buton next to save (so we have Save and Cancel), the word would
be "Anular".
To make things even more confusing, Cancelar is synomim with Suprimir,
which translated back to English means Delete. Or Cancel definately
does NOT mean Delete in English.
And old French proverb says "Translations are like women - if they are
beautiful, they are not faithful; if they are faithful, they are not
beautiful."
If you want your application to look natural for a spanish native
speaker, ask someone to translate it, string by string, but do not
send only the strings. Send screenshots of your app and send the
context where that string is used, because the translation depends on
that.
Thanks for reading this.
I will conclude here this long message with the rule I have in my
multi-language applications. There's no rule and you can't assume
anything. Just translate the text as is. Yeah, that's right, you may
end having duplicate tranlations in the dictionary. And who the hell
cares? And they're duplicates for one language, but not for another.
Just go for storing each and every string found in your application
On Tue, Feb 2, 2010 at 4:20 PM, Stephen Russell <[email protected]> wrote:
> On Mon, Feb 1, 2010 at 8:09 PM, jerryF <[email protected]> wrote:
>> I wrote a program for a client of mine who is Spanish, now he wants me to
>> rewrite the program in Spanish. Is there any easy way to do this?
>> Do I have to modify all of my labels by hand?
> -----------------------
>
> The bad news is Yes you will have to rewrite the interfaces. The
> positive side is your code base should now have new functionality that
> you can use over the future.
>
> The leading add on for Fox has already been stated as well as someone
> doing it. So those are the options, spend the money to save time or
> roll your own. Back in late 90's we rolled our own. Every screens
> dbf file was scanned for labels and when found we put that reference
> into a new translation table of elements. We then added the
> translation literal table as well as the translation language table.
> We then added a function to each screen that updated the label
> display.
>
> At the time we were attempting to sell in Canada and were asked to
> present a French version for a limited area. This whole process took
> about two days to implement. We added a French text by placing "la" in
> front of every text string. We told the client that our crack Cajun
> translators ran the first pass but they could tweak it where
> necessary.
>
> What a long strange trip it's been.
>
> --
> Stephen Russell
>
> Sr. Production Systems Programmer
> CIMSgts
>
> 901.246-0159 cell
>
[excessive quoting removed by server]
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
