Multilingual ValueLists

by Matthew Leering

MultiLingual ValueLists Interface




In a former post, I provided a simple technique to allow FileMaker Developers to put multilingual labels on their layouts.  That tackles the majority of the multilingual requirements for the average system.  In some cases however, we need a little bit more multilingual integration in our systems.  This module will provide you with a means to create and edit multilingual valuelists in your solution.


Integrating this module into your existing solution should be relatively simple.

You will need to:

Relationships To Copy

  1. Copy/Import tables from this module into your solution (no need to copy the “~Contacts” table as it’s just a sample
  2. Recreate the relationships in your solution (see sample image)
  3. Copy the “Edit Value Lists” layout into your solution (It’s based on “Defaults” )
  4. Attach “Get List Of VL Tables” script to the OnLayoutEnter script trigger for that new layout
  5. Run the “Get List Of VL Tables” script



Creating New Value Lists

This will also be extremely easy.  You will need to:

  1. Duplicate one of the existing “VL_” tables (new table name must begin with “VL_” and field names must remain the same)
  2. Ensure that a new layout got created when you created that table (it doesn’t have to show up in the menu, but it must have a name that matches the table name)
  3. Create a relationship to the new TO (starting from “Defaults” relate it to your table with a cartesian product)
  4. Create a value list (I recommend duplicating one of the existing value lists, and just repointing the zc__recordSerial and userValue fields to the same fields in your new table)



The values in the value lists that you use throughout your system will be dependant on the value chosen in the global field in the “Defaults” table.
If the value is 1, then it will use the first column of values (the first language), 2 will represent the 2nd column of values… and so on.

This system is currently set up using 5 repetitions, and this allows it to support up to 5 languages.  If you need more languages, simply increase the number of repetitions on all the repeating fields, and make sure that those new repetitions also show up on your layouts.


Special Notes

This technique relies heavily on the usage of Virtual List tables, and uses “Get ( RecordID )” instead of an actual serial number within the tables.  This makes it easier to setup and use, but because it’s set up like this, I want to make sure that you do not provide any interface for your users to delete records from your “VL_” tables.  You could provide buttons that would make them think they’re deleting records from that table, and really just clear the values from the record instead if your users require that kind of functionality


Download –>


9 responses to “Multilingual ValueLists”

  1. Tom says:

    This is great. The example file works like a charm. When I imported it I am getting an error for missing or deleted script with the Edit Value Lists table. It seems like it is hanging up on entry to any field. I click OK and enter the data. It saves the entry, but every field change I get the error pop up and need to click again.

    I will create a new one from scratch and see if it goes well from there. The example file did not have any script triggers on entry that I saw.

    If you have any suggestions that would be great.


    • Hi Tom;
      Glad you’re going to be able to make use out of the functionality this module provides.

      As for the problem you’re running into, it sounds like you might be missing some scripts and/or fields when you’re copying it over to your own solution.
      What I recommend you do when copying the layout is the following:

      1. Create a blank layout with the proper name
      2. Make sure the “target” layout has the same parts as the “source” layout, and that all the parts have the proper size to them
      3. Select all layout objects (CTRL+A) on the “source” layout, and copy them to your clipboard
      4. Paste all those layouts onto your destination layout.

      If you take a close look at the “VirtualListOfVLValues” portal, you’ll notice that there are actually 2 stacked fields there. Each of which contain 5 repetitions. The field at the back is actually a global field, and needs to exist in order for this interface to properly work.

      It’s a little bit of FileMaker trickery if you will.
      Basically, since the portal is only displaying a Virtual List instead of real records, then updating those virtual records themselves wouldn’t really accomplish anything. Because of that, I use global fields and script triggers to make updates to the proper spots.

      That global field at the back has 3 script triggers:
      – OnObjectEnter – “Click Into Value List Entry” –> This basically gets the system to know which repetition number you clicked into (so it knows which language to modify), as well as which record number in the portal (so it knows which value to modify)

      – OnObjectSave – “Save Change To Value List Entry [ _newValue ]” –> This makes sure that enough records exist in the virtual list table, and If indeed a change was made to the global field, then it’ll update the proper repetition of the proper record in the proper table.

      – OnObjectExit – “Clear Language Entry Globals” –> This just clears the values of the global entry fields

      I hope this helps clarify things for you.

  2. Tom says:

    After using this a few times in a single file I am having trouble getting this to work with data separation. Everything looks to be working and the multilingual labels work fine. I tried with this moved to the UI file and no luck. also tried using the value list from the data file but no luck. Keep getting value lists with no values defined. All the records are there and all the VL tables are recognized. Running through all the scripts the debugger seems everything to be working.

    Any general advice on what I might be missing?

    • Hey Tom;
      You are right that the bulk of this would have to exist in the UI file.
      If when stepping through, everything seems to look proper, then I would suspect that recordIDs might be out of whack.

      Instead of using regular serial numbers in the virtual list tables in this example, I had used auto-enter calcs that evaluate to Get ( RecordID ). These can be problematic if for instance a record ever got deleted in that table. I would inspect all of them to make sure that they are all indeed sequential, and begin at 1. If they don’t, then the easiest fix is probably going to be to change them to real serial numbers, and do replace field contents on them so that they are proper.


  3. Tom says:

    The IDs are still good. I will keep working on it and see how it goes. Now that I understand how it works I may be able to modify the process just a little bit. I really need the translations available in the data file for a certain task.

  4. Tom says:

    I figured out the issue. I missed changing one relationship to defaults from “=” to “x”. I moved Defualts table in last and it should have been first into the new UI file. The calc for user_value in the VL tables were broken because of this.

    Seems to be working good now.

    I do have one question: Do I need to run the get VL_tables and get VL_values scripts every time I change the language? It seems maybe I only need to do that once at file opening. FM14 seems to handle the scripts a little slower than 13.

    • Easy thing to miss Tom.
      Pretty sure I’ve done the same, myself.

      With regards to your question though, I think I’m a bit confused.
      In my demo file, I don’t think any scripts get run when a user changes the language.
      If I recall correctly, the two scripts that you’re referring to are used solely to populate the virtual lists that drive the value list admin area.

  5. Hi Matthew,
    The solution works like a charm. It safe my life. Thanks a lot from France!

Leave a Reply

Your email address will not be published. Required fields are marked *