1 2 Previous Next 19 Replies Latest reply on Apr 25, 2015 7:45 AM by Peter Wagemans

    Localizing your Solutions - A request

    vince.menanno

      Hi everyone,

       

      I’ll be doing a session at DevCon that talks about building solutions in multiple languages - basically, building support for localizing your solution. I am doing a survey of the different techniques that are currently being used in the community.

       

      If you have built a solution that runs in multiple languages and don’t mind sharing some information with the community.

       

      What I am looking for is:

       

      How many languages does your solution currently support

      The techniques used to switch between languages

      The techniques used to show the localized text

      And anything else that you might want to add or mention about your experience in localizing your solution.

       

      Can you contact me backchannel at vince@beezwax.net about your solution.

       

      Thanks

       

      Vince

        • 1. Re: Localizing your Solutions - A request
          ibrahim_bittar

          Hi Vince

           

          I've just sent you a detailed explanation of my method. Let me know if you need anything else.

           

          Regards

           

          Ibrahim

          • 2. Re: Localizing your Solutions - A request
            vince.menanno

            Yes I see it - thank you so very much.

            • 3. Re: Localizing your Solutions - A request
              TimDietrich

              Vince -

              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.

              - Tim

              • 4. Re: Localizing your Solutions - A request
                TimDietrich

                Oops. Here are the files... I think.

                 

                Screen Shot 2015-03-30 at 7.10.14 PM.png

                Screen Shot 2015-03-30 at 7.11.34 PM.png

                Screen Shot 2015-03-30 at 7.11.12 PM.png

                • 5. Re: Localizing your Solutions - A request
                  vince.menanno

                  Thank you Tim. this is great stuff. Will be in touch with you.

                  • 6. Re: Localizing your Solutions - A request
                    Benjamin Fehr

                    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:

                    NightWing Enterprises - Multi-Lingual Interface demo for FileMaker Pro

                     

                    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

                    • 7. Re: Localizing your Solutions - A request
                      vince.menanno

                      Awesome,

                       

                      Thank you for bringing this to my attention.

                       

                      Vince

                      • 8. Re: Localizing your Solutions - A request
                        taylorsharpe

                        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!

                        • 9. Re: Localizing your Solutions - A request
                          Fred(CH)

                          Hi Vince,

                           

                          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 !

                           

                          Fred

                          • 10. Re: Localizing your Solutions - A request
                            Markus Schneider

                            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..

                            • 11. Re: Localizing your Solutions - A request
                              vince.menanno

                              Fred,

                               

                              Thanks for this info - any small example that you can send me so I can demonstrate your technique that would be helpful.

                               

                              Thanks

                              • 12. Re: Localizing your Solutions - A request
                                vince.menanno

                                Markus,

                                 

                                Any small example file showing your technique would be helpful if you could send it. Thanks

                                 

                                Vince

                                • 13. Re: Localizing your Solutions - A request
                                  cstavrou

                                  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.

                                  • 14. Re: Localizing your Solutions - A request
                                    miler24

                                    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!

                                     

                                    -Eric

                                    1 2 Previous Next