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.
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 ; "" )"
[ "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:
from a web browser:
from Filemaker Pro:
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 22.214.171.124 - 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.
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.