I'm looking at doing this to. I'm wondering why property profiles haven't been mentioned in this thread. Seems like they would be a good solution, with one profile for each language.
Pete lcSQL Software <http://www.lcsql.com> Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html> On Sun, Jan 18, 2015 at 1:27 AM, Graham Samuel <livf...@mac.com> wrote: > I very much like Kee's approach, though there is an issue about populating > the list of texts for the elements. I was involved in a project (which in > fact was never finished) where we had to get all our texts translated from > English into a language we (the developers) didn't know, Welsh. So we sent > out a simple text document to a native Welsh speaker, with each text on a > separate line, and got back a line-by-liine translation. In order to make > it less tedious to then place each text into its appropriate custom > property 'by hand', so to speak, our equivalent of the "loadLanguage" > command for each text simply loaded the text for the element from the > appropriate line of the text file for the particular language. So each text > element (button etc) had a built-in identifying number which corresponded > to the appropriate line number in the list of texts. This approach would > have also made it very easy to add new languages. It was obviously an easy > job to add such text files either externally at run time or internally > during the development process. > > Graham > > > > > On 18 Jan 2015, at 06:07, kee nethery <k...@kagi.com> wrote: > > > > > >> On Jan 17, 2015, at 1:54 PM, Ethan Lish <ethanl...@gmail.com> wrote: > >> > >> Is there a defined approach, tool or general guidance on how best to > design & develop a livecode app to support a multilingual user interface. > > > > My approach was, for each text element (button, field), to create a > custom property named for the language “en”, “fr”, “de”, and then put the > translations into the custom properties. On opencard I would send a > “loadlanguage" command (that I wrote, you can call yours whatever) to each > element and populated the element with the appropriate translation. In the > corner of each window I had a language selector and if the language was > changed, I’d send opencard which would send loadlanguage to each element. > > > > If the language custom property was missing for that language, and there > was a “en” custom property, I’d use that. Also, if there was an “en” > property, I’d create the other properties and populate them with the > english translation. If there was no “en” custom property, I’d not alter > what was being displayed by the element. > > > > I found it useful to create a command that set the language to “ww” and > then for each card, I’d measure the length of each translation and insert > the longest translation regardless of language. I could then adjust the > buttons and fields appropriately knowing they would work properly > regardless which language was selected. > > > > That is what I came up with when I was playing with a multi-lingual > Livecode project. Seemed to work pretty well. > > > > Kee Nethery > > > > > > > > _______________________________________________ > > use-livecode mailing list > > use-livecode@lists.runrev.com > > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > > http://lists.runrev.com/mailman/listinfo/use-livecode > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode