I've just sent you a detailed explanation of my method. Let me know if you need anything else.
Yes I see it - thank you so very much.
Congrats on being chosen as a DevCon speaker!
If you're looking for Custom Web Publishing solutions that support localization, then I'd be happy to share details of how FMEasyWeb supports it.
In FMEasyWeb, all of the terms (such as "next," "previous," "continue," "login," and so on) are pulled from a dictionary file. There's a user-configurable setting that makes it very easy for them to switch between language dictionaries.
It currently has support for English and Spanish dictionaries. The Spanish dictionary is a mess, because I don't speak Spanish (yet!). I'm hoping that others will add additional languages in the future.
Attached are a few screenshots. One shows what the dictionary looks like in PHP, and the others show the login form with the language set to English and Spanish.
If you want to chat more about this, let me know.
Thank you Tim. this is great stuff. Will be in touch with you.
How many languages does your solution currently support
4 - German, French, Italien, English
The techniques used to switch between languages
A technique introduced by NightWing Enterprises:
Language is indexed as 1 - German, 2 - French, etc.
a value list is a separated table with a global field for language-N° [g_Language].
The values itself are in a repeating field [value]. => 1. Repetition is German, 2. Repetition is French, …
a formula field shows chosen language value by calculation [f_Value] = GetRepetition ( value ; g_Language )
The startup script sets the language-N° in all value-list tables [g_Language]
not very sophisticated but it does the job
Thank you for bringing this to my attention.
I remember at a Devcon a couple of years ago of someone getting me away from fields with Yes or No and going to Boolean numbering (1 = Yes, 0 or empty = No) because this can be implemented across multiple languages more easily where a Yes is something else in another language.
Actually, I've not really tackled dealing with foreign languages before, but it sounds like an interesting presentation. I'll have to sign up and attend, Vince. Looking forward to it!
The basic principles of the solution i just built are following :
A center database file, called "string" or "dictionary" can be used as an external datasource by all the operating files of the solution.
In this string file, two main tables : "String" and "Global".
The String table have a Code / unique ID field and one field for each language. Easy to extend, just add a field to add a language. In this table, obviously, each string is a new record.
The Global table have one global text field for each string. This is precisely used on all operating files to display strings in the current language. Generally, the OT name is only one char length, to facilitate merge fields. Ex : "<<S::FirstName>>" (please note this cool trick, thanks Matt Petrowsky) .
In the dictionary file, a looping script, used when changing the language reference is loading each string on the appropriate global field which is named as the string ID. The Set Field by Name script step is obviously very useful on this step.
But one key idea of the system is following : when the global field doesn't exist yet (error capture when setting the field), it is created "on the fly" by an Execute SQL script step that auto-target the database file itself as an ODBC datasource.
The repeating fields are not used in this system. Essentially, because they could not be used in merge fields.
I cannot send you the work itself but hope that give you one or two ideas and another point of vue.
Good luck !
WE support as many languages as a customer needs - but only for outputs. The interface itself is in the language that the cutomer wants. The specific label-texts for fields are really different per language (much more characters in one language than in another..).
TExt for outputs is hold in separate tables, the standard (=customers language, could be '1', 'DE', whatever) language serves as key - so, in the overview of the dictionary table, we got for every entry the customer's text and the foreign text side by side.
THere is always a key for an output text, combined by layout-type and language (and more, one output layout might serve for more than one document-type)
OUtputs are more standarized than the interface - the interface is subject for changes here all the time )-:
WE got a standard solution as well - but not two customer-versions are identical..
Thanks for this info - any small example that you can send me so I can demonstrate your technique that would be helpful.
Any small example file showing your technique would be helpful if you could send it. Thanks
Same kind of idea as everyone else, but I use a separate table with a record for each field name, text box, button or whatever. The first record is English. Each additional language is a separate record to which a global language variable from the main table is linked. The language table should have a very short name - I use "la". Each field in "la" is a short form of the text, eg. "cont" for continue. Each button, text block, etc. is put onto a layout in a Merge field so the continue button would be <<la.cont>>. Value lists are a bit more complicated, but the same idea. What's nice is that if someone volunteers to translate for you, you can give them a copy of the "la" database. Create a new record for the new language and a have a layout that shows each field from the English record and the field from new language record next to each other. The translator just fills in the fields and another language is supported.
Plolyglot calculations are really difficult, but I would imaging that would be problematic in any solution. For example, in an output like ("You entered the word " & <<la.word>> & ".") the German version would have to be ("You have the Word " & <<la.word>> & " entered."). This can certainly be done with something like (<<la.enter_word_prefix>>&<la.word>>&<<la.enter_word_postfix>) but you have to know the language yourself or your translator has to understand what you are trying to do in the calculation.
Our "Kosmas" solution uses a centralized language table in the data file for which all interface files (Pro, iPhone, iPad, WebDirect) will cache locally (updates only happen if a change was made) then load the user's chosen language into global variables. All layouts use merge variables. It's fast to load over WAN (due to local caching), can have an infinite number of languages and has the added bonus of allowing users to modify their own labels and buttons without giving them access to layout mode.
We currently support English, Spanish, Chinese and Korean but are adding dozens more (it's very easy to add more). To see it in action, download our demo (runtime) at www.docuwrx.com, click, "Pricing", click "Demo" and enter your email address.
Have a wonderful day!