Canonical Coding
Doing your best to create a robust FileMaker solution is likely part of your goals and objectives. However, until you know how to approach some aspects of your solution design, you can easily spend a lot of time creating something which can be both hard to maintain and upgrade.
This is where canonical coding comes into action. The objective with canonical coding is to put a number of things specific to your whole solution in singular locations. This is also covered by the premise of DRY (Don't Repeat Yourself) coding.
In this video, I showcase my new technique file which I'll be using for my FileMaker 12 examples. Much of what is covered can also be accomplished in older versions of FileMaker as well. The video shows you how to implement a localization model which takes advantage of "Settings" layouts.
If you've not used "Settings" layouts then you're likely putting a lot of text into a lot of places where changing that text at a later date will cost you a lot of time and effort. Watch this video if you're interested in making the most robust possible solution you can with FileMaker Pro!
Comments
Canonical Coding
I am working on a dictionary of theater-technical terms with a multilingual interface. As your Canonical Coding took as example the change of language interface, I was very interested. But perhaps I am not well understanding something of your technique (I am not a native English speaker). You seem to need a separate layout for each language, where I am working with 1 layout with all needed texts coming from a Merge Field coming from a Table with a record for each language containing the translated layout texts, with as link a global field for the language chosen by the user. Of course, I still would like that a language would be chosen automatically according to the language of the system of the user (not the language of their FileMaker, as they approach mostly with IWP).
I am remaking the application, and each simplification is welcome. For the moment it works too slow, certainly due to unnecessary complications. Unfortunately I can't work with Conditional Formatting and Script Triggers due to the IWP approach.
You can find my work as it is now by downloading a pdf with link from
http://www.oistat.org/media/dtw/dtw_manual_2012.pdf
The Guest Account needs no password.
Thanks for your attention and best regards,
Jerome
There are many ways
To solve the problem of translation. You can certainly take the approach you have and use a dedicated table. The foundational premise is having the language string in on singular location. If that's text within a label, or text within a field then you've achieved the goal.
Yes, in the video I presented a solution where each language would use it's own layout, however, I also mentioned that you could also use zero layouts and simply put the translations on the layout with a specific object name and parse that object based on it's name.
What is presented does not take IWP into account and if you are doing things for IWP, then there are other things to take into account. First, the OS language is not something (that I am aware of) that you can determine at runtime. You would need explicit input from the user as to what language they wanted to use.
I don't personally use IWP so there are many things I'm likely unaware of with regards to what a best approach would be. Certainly, in this case I would not recommend what is presented in this video.
Matt
-- Matt Petrowsky - ISO FileMaker Magazine Editor
Canonical Coding - Re: Go to Layout ["$$localizedLayout"] !!
Hi Matt - Perhaps I’m missing something! My understanding is that:
Go to Layout ["AnyLanguage"]
If [Let ( $$localizedLayout = Get ( ApplicationLanguage ); PatternCount ( ¶& $$localizedLayout &¶ ; ¶& LayoutNames ( Get ( FileName ) ) &¶ ) )
Go to Layout ["$$localizedLayout"]
End If
Would revert to the default language given by ‘Get ( ApplicationLanguage )’ if for example the native application language is English and the above code says ‘Go to Layout ["French"].
My own experience is that setting ‘Go to Layout ["French"] will alwats go to the ‘French’ layout on startup and the script does not direct to English where the OS/appliaction langauge is English.
So I’m wondering what I've overlooked as if the OS is French and the Startup script includes ‘Go to Layout ["English"]it would appear to always default to the UI.ENGLISH.XXXXX (????)
Steve
Layout Based Localization of Globals
Hi Matt,
Great video! At about 31:30 you begin talking about localizing on a layout by layout basis. My question is when you have a layout startup routine that sets global vars. What do you do on layout exit (if there are globals specific to a certain layout that dont appear on another—and so wont be overwritten when you switch to another one)? Do you set those globals to null? or do you just leave them as is?
Quick Update/Thought... Can't you just use locally scoped variables?
thanks
-P
Flags
Hello Matt.
Any ideia were I can find the flags for other countries, how can i do them?
Thanks.
Awesome Video! I like the
Awesome Video! I like the video and its very informative but the one thing im new to is the language part. Im new to Filemaker still altogether but you mentioned localizing it to the language byt creating a layout for each language and copying that let statement to the other layouts. Is there something else i need to do like change the text to the language of say french on the french layout or what?
Mark Johnson
Aroma Impressions
mark@aromaimpressions.com