5 Replies Latest reply on Oct 14, 2014 1:15 PM by NickLightbody

    Designing for language

    NickLightbody

      Whether we want to serve merely our mother tongue or offer multiple languages in our WAN deployed FileMaker App finding an appropriately efficient means of displaying language is essential.

       

       

      By language I mean all language, field labels, button labels, dialogue text, error messages, help, about, every single langauge item used anywhere in your App.

       

       

      If you want to cover FM WebDirect then using language as opposed to icons for buttons is a simpler and faster option.

       

       

      In traditional systems this was often done using a web of additional relationships used to drag data from a language table into the correct contexts or language was stored in a large number of global fields - which themselves needed to be populated and capable of being edited whilst deployed on FileMaker Server.

       

       

      When designing for performance we know that we need to work out how to ask FileMaker to do as little as possible to ensure good or great speed - hence avoiding the use of or minimising the use of relationships for language is logical. This is because the moment you create a relationship you are asking FileMaker to access and cache what it can "see" from the current context throughout operation - so using relationships for language adds to that work and hence is best avoided if a viable alternative can be found.

       

       

      Nowadays the most efficient method is to "publish" your language to global variables - which have the additional advantage that they - like merge fields - always display perfectly in FM Web Direct - whereas some actual fields may not always quite display as you would hope at present.

       

       

      Inserting global variables into your user interface is easy, display is fast and this method asks very little of FileMaker.

       

       

      An example is shown below - this is the layout for the Language Editor referred to below.

       

       

      The possible issue to bear in mind is that global variables do take up memory space so that if you published a very large number - many thousands - then FileMaker's performance may drop as memory for the Application seems to correspondingly be reduced. I demonstrated this under FM9 or 10 a few years ago but have not observed this issue under FM12 onwards so it may no longer be applicable.

       

       

      The challenge then is in designing a system to enable you to create and edit language strings and then to "publish" them efficiently to your global variables.

       

       

      The first part is clearly just a matter of preference - you need a table into which to put your language - with an appropriate management interface - and - if you wish to offer more than one language you can use a repeating field for the text to be published so that - for example - US English is in repetition 1, Mexican Spanish in repetiton 2 etc.

       

       

      An example of this type of Language Editor is shown in the attached screen shot - the sliding panel offers access to various different language repetitions.

       

       

      The second part is how to publish your carefully crafted language? The method I have found works best for me uses a simple loop to step through the language table and create the relevant global variables - in this case using the appropriate repetition from the language table in order to publish the appropriate language. It is efficent and currently - over a 250 mile WAN - it takes less than 1/10th second to publish 234 globals. It is important that you write this efficiently since you will realise that it cannot be written as a server side script since it needs to publish into the current user's own session - which a server side script would not do - since it creates a new different unique user session for that one script call.

       

       

      Context: this particular App is a single file App running on a low powered WAN server, a 3 year old Mac Mini Server - OS X 10.9.4 - 2.66GHz Core 2 duo - 8GB 1067 Mhz DDR3 - sited in a UK data centre.

       

       

      The trickiest part for me was finding out how to auto publish the global variable - here is my method - although I did this a couple of years ago I think I recall getting the key bones of this from Kevin Frank's excellent blog - http://www.filemakerhacks.com - sorry not to be clearer on that attribution - it was a little while ago.

       

       

      Let ([

      variableName = langData::a1PublishTo ; // the global variable name specified in the language table

      variableValue = langData::a1RecordTitle[$$Lang] ; // the langauge string to be used from the repetition for the selected language

      formula = "Let ( variableName = variableValue ; "" )"

      ];

      Evaluate (

      Substitute (

      formula ;

      [ "variableName" ; variableName ] ;

      [ "variableValue" ; Quote(variableValue) ]

       

      ) //close Substitute

       

      ) // close Evaluate

       

      ) //close Let

       

       

      An example of this method in use can be seen here on the free trial of the Deskspace new App:

       

       

      US:

      from a web browser:

      http://64.64.194.79/fmi/webd#dApp_0070

      from Filemaker Pro:

      fmnet:/64.64.194.79/dApp_0070

      from an iOS device using the Free FileMaker Go 13 App - available from the Apple App Store

      from the Home page create a host at 64.64.194.79 - which you can name Trafalgar

      select file dApp_0070

       

      If you provide your name and email when first using this App - which you do not have to do - then your account will be upgraded to give you access to the Language Editor built into the App as described in this article. If you have an interest in these methods you are welcome to contact me.

       

       

      Cheers, Nick

       

       

      Disclaimer: These are purely my own views - you use my methods at your own risk - please feel free to disagree and/or suggest improvements to this methodology - the reason I am writing this series on performance is that I believe that the WAN performance offered by the current versions of FileMaker Pro, FM Go and FM SWebDirect is considerably better than many folk give them credit for - but you do need to understand and play to FileMaker's strengths and not burden it with unnecessary tasks - so modern good design is the key.

        • 1. Re: Designing for language
          bigtom

          I use something based on the multi-lingual stuff done by Matt Leering. Uses Global Merge fields with language repetitions for static text and repeating field virtual lists for drop down menus. Similar to what you have going. It is pretty fast.

          • 2. Re: Designing for language
            filemaker@i-absolute.com

            I'm interesting in this method, but what about when you have to see control a particular variabile, in the data inspector? Could be a thousand of global variables. This also has impact on performance. Right?

             

            Cheers,

            Fabio

            • 3. Re: Designing for language
              ibrahim_bittar

              Hi Fabio

               

              The only downside in my opinion is that your data viewer will be crowded with variables, otherwise is pretty fast.

               

              I tested Nick's solution connecting from Mexico to UK and it works VERY fast, considering distance, bandwidth and network latency.

               

              In my case, I'm developing a solution which will have around 6000 strings, among field labels, script dialogs, value lists and so on. In this case I prefer to use global fields for Field Labels as they are easier to format and resize and won't clutter my data viewer.

               

              I believe that if your solution will use a few hundred strings then you'll be fine with Nick's technique.

               

              Regards

               

              Ibrahim

              • 4. Re: Designing for language
                filemaker@i-absolute.com

                Hi Ibrahim,

                I used this similar technique by Matthew Leering, but my problem was the crowded data inspector.

                http://www.modularfilemaker.org/module/labelmaker-pro-enable-multilingual-field-labels-for-your-filemaker-solution/

                 

                So i prefer yours technique, but performance in WAN degrades.

                 

                Cheers,

                Fabio

                • 5. Re: Designing for language
                  NickLightbody

                  Hi Fabio,

                   

                  Thanks for your comment.

                   

                  I haven't noticed the variables in the data inspector as I am just watching the ones I want in the watch panel - but yes of course you are correct that they will clutter the left panel - but as users never see the data viewer just our use of their language I don't mind that price.

                   

                  With FM13 I think you would have to have a very great length of text in globals to have much impact on performance - it would be easy to test - maybe I will try and see how much is required to make a significant difference. Under the .fp7 format a trial with several thousand $$vars did slow a system, .fmp12 is I think much more capable.

                   

                  Thank you Ibrahim for your comments.

                   

                  My general view is that $$vars are more efficient and offer better performnace than global fields. Also $$vars seem to format and display more consistently in FMWD than fields - from my observations - which I why I decided to use them rather global fields - but depending on circumstances there could clearly be a case for either method.

                   

                  The key in my view is to make an informed choice - hence my effort to start some dialogues on these performance related design issues.

                   

                  Cheers, Nick