4 Replies Latest reply on Apr 3, 2014 8:32 AM by ColinH

    Translation (equivalent value lists)?



      Translation (equivalent value lists)?


           Hello... I'm sure there is a simple way of doing this...
           I am creating a database that is mainly in French. One of its functions however will be to produce an English translation of a standard document (in its own Layout, intended for printing). I need this particular layout to display English translations of various fields in my French database, most of which are value-lists (so, simple one-to-one translations). Of course I could create new calculation fields for each English term that needs to appear on the English layout, but that seems a little heavy-handed, especially as the correspondences are direct and invariable (so tokens a, b, c in French value-list 1 will always correspond respectively to tokens x,y, z in English value list 2). Can I not use table relationships somehow to create a kind of "translation table" (like a localisation file I guess) that automatically aligns values in the French fields with English equivalents and displays these on my English layout? Am I making sense? It strikes me that this should be easy, but for some reason I can't see how to do it...  Many thanks for any help.

        • 1. Re: Translation (equivalent value lists)?

               Yes, a lookup table that pairs equivalent French and English terms should be possible. Where or How do your efforts to set up such a table fail?

          • 2. Re: Translation (equivalent value lists)?

                 Well, it was more a question of not clearly seeing how to attack the problem...  I have since come up with a solution that seems to work... perhaps you could comment on it?

                 I have created a new table (TranslationTable) that holds global repeating fields for each value category in both French and English (so Field1Fr, Field1En... etc). The translation equivalents have the same repetition number (index) in their respective fields. The French values are set by calculation fields in the main database that return an integer based on several user-inputs. This integer is then used to call the correct term from either the French or the English repeating field as required (with a call like =TranslationTable::Field1Fr[RepIndex] ).

                 Does that seem like a reasonable solution, or am I over-complicating things?

                 What I didn't want was for the French/English terms themselves to be hidden away in calculations. I wanted to be able to get at them easily and edit them if required. This solution allows that with a dedicated "lexicon" layout that displays all the repeating fields as editable.

            • 3. Re: Translation (equivalent value lists)?

                   It seems overcomplicated and inflexible as your repeating field has a limit to the number of values you can put into it. A related table has no such limit.

                   Nor would I put the translated terms inside a calculation.

                   I would define a new table where one field stores a French term and another the English. Adding or editing the terms in either language then becomes a data entry task and you have the option to add more terms whenever this is required simply by adding more records in the table.

                   This table can also serve as the source of values for your value list. Then you can either use different layouts for the French and English terms or you can use the same layout but with calculation fields that refer to different fields of the same related record to control whether French or English terms appear in the field. There are, in fact, several different ways to show the terms from the related table. If you set up your value lists to enter an ID number from the terms table, you can even have two pop up menus defined, one that shows the French term associated with that ID number and one that shows the English equivalent.

              • 4. Re: Translation (equivalent value lists)?

                     Dear Phil(?)

                     Your answer actually made me realize that I'm using the program in really weird ways...  My BD is still small enough that a complete overhaul is not a daunting prospect, so that's what I will now do... incorporating your suggestion as I go.  Many thanks (the new version will be much more sensible... )