1 Reply Latest reply on Jul 10, 2012 3:59 AM by Hans

    Multi-language solution


      Hello all,

      I'm doing a database in-house that takes care of sending students to universities around the world. Size-wise we are talking 5-8 main modules and maybe 20-40 tables.

      In case more that two languages must be supported, possibly due to the solution being sold to a similar company, I am considering the pros and cons of designing af multi-language solution. It could involve making the layouts 'smart' so static text labels would be fields. Or I could duplicate layouts to have a version for each language; not quite as smart, but at least re-using the TO's.

      Apart from Custom Dialog buttons, what would be caveats / showstoppers? Can you point to any business cases where doing a multi-language design was worth the trouble?


      Jens Rasmussen

        • 1. Re: Multi-language solution

          Hi Jens


          I totally agree with Egbert/Pixi. Having all text and helptext (tooltips), images, icons and menus stored in a parameter-table makes it much easier. About 10 years ago I decided that everything I would develop in the future should support multiple languages and I never regretted. This makes it much easier to manage. You also get the benefit that if you mistyped something wrong you only have to correct it one place and not on several layouts. In a multi-culti world there's always a big chance that it could be a showstopper if the solution don't support multiple languages. The enduser also may need to use the system in one language and print out something in another language.


          Some of our users have multiple forecast and reports sent daily (by a scheduler)  to foreign nations and then its nice to just tell which language they should be in.


          However I use a slightly different method than Egbert. Feel free to use it if you want.


          At first all my users are stored in a separate file - I don't use FM's own because I have more than 1000 settings for each user and an administrator should be able to manage this without getting access to the FM Accounts and Priveleges-"area". The user should also be able to change some settings him/herself - like what preferred language to use and what helptext-language to use - they may be different!


          In  that same file - but in a parameter-table (only one record) - i create all my metadata. I use repetition-fields and each repetition shows it's own language. Like 1: Danish, 2: English, 3: German, 4:Swedish...etc. Doing it this way means that I can update live systems easily.

          The fields must NOT be global's. I did that mistake and had to rewrite it all which took more than 4 weeks.


          All metadata is actually first created outside in Excel - in this way I can easily send the Excel (or parts of it) for translation. It's also much easier to find the relevant data in Excel and to copy fields etc. I have about 9000 fields (rows) in Excel. When I'm in layout-mode wants to put in a field name or a helptext then its easy to just go to excel and find it. I could find it in Fm but then I have to go to the Users-file and find it in browse-mode - and then go back again. This takes much to long time.


          I manage field names this way in FileMaker:

          All text-fields starts with t_    and all help-text starts with h_

          this makes it much easier to manage speed of usage later and prevent mistakes.


          I have a maximum of 6 characters in the field-names including the t_ and h_

          The fieldnames also gives a hint of what it should represent so if I want "Back" on a layout - the field-name is called t_back. It is very very important that the field names have the same length and are as short as possible.

          In the users-file I have 2 layouts with the parameter-table and all the text on one layout and all the helptext on another layout. On each layout I put tabs for each letter A,B,C..... I have more than 9000 fields and it's much faster this way.


          My method is here slightly different than Egberts.


          In the other files - invoices and letters, activities, emails, products, accounting etc., users may want to hit the language-flag-buttons - but I don't use lookups to change the language. I call a script in the Users-file to first store the language (so it's remembered until next time he/she logs in) but it also SETS all the global text fields that I created in the other files. They have the same names than in the parameter-file but they are global's so each user can see the text in his preferred language


          Egbert uses lookups but I prefer this other solution. This also makes it a bit faster because I have several Instant Web Publishing Portals inside some of my files and there I may only want to update some parts of the text in that solution and not all of the textfields.



          The user may or may not want to see helptext. The user can change that himself but if he wants English then he hits the English flag and the representing language-number is stored on the user-profile. All helptext is not getting set in the other files and again no look-up is needed. The helptext is only set once in the parameter-file and then I put something like this as a tooltip on an object:


          If(Customers::LanguageIDUserHelp>0; GetRepetition(Global1_UsersPar::h_ecui; Customers::LanguageIDUserHelp);"")


          This just tells FM that if the user don't have a language number for helptext (tooltips) then show nothing...but if theres a language-number then just take that repetition and show that. Its very easy and extremely elegant to use. In this case "h_ecui" shows "Edit customer information"


          Please remember that in my solutions the user may want to see the layouts in one language - but the helptext in another language. So I store 2 language-numbers - one for what's shown on the layout and another for the helptext.


          Another really great benefit is that you can much easier copy metadata and fields + helptext from one solution to another solution.


          If you create a new file - then just remember to make the same relationship-name (like "Global1_UsersPar" and copy the tables and everything also. Then import the metadata into the paramater-table.  Then you can just copy fields and field-names from the old solution and paste them into the new solution. Helptext and everything works without you have to do anything. In this way you may save many hours and have an easy way of administrating the metadata.


          Ther's also some other great benefits ant tricks to use - but this is mostly the case when you have +2000 fields and may want to create 300-500 new fields in a very short time. Feel free to contact me if you may want to see how that works