I have internationalized my app manually so that I can switch languages on the fly, but the basis of my internationalization relies on the built in multi-lingual capabilities of Strings in Xojo. So every string in my app has a default value as well as an English and Spanish value.
I keep them all in a Strings module, and there are several thousand of them for the full app. In Xojo 2013R3, adding a new constant to this module takes nearly a minute - i.e., I press Command-Option-C (add new constant keyboard shortcut) and then the spinning beachball of doom comes up for anywhere from 30-50 seconds, and one of my processor cores (I have 4) gets pegged. Then the add constant panel appears and I can type the name for the new constant. Then I click into the “Default Value” field, and get to wait another 30 seconds or so. Then I can type the default value. Once this is done, I can quickly add the English and Spanish variants and move on.
I have hundreds more constants to add for our upcoming release… PLEASE tell me there is a faster way?
Here is an example movie - takes me a little over 2 minutes to add a constant. This used to take me about 20 seconds - most of which was navigating around the UI to select languages, etc.
Note that my screen capture software does not capture the spinning ball, so you’ll just see a mouse cursor… but I move it around on the screen to show that the video is still running, and I’m still waiting for the UI to respond.
Has anyone else seen this? I can’t find anything in Feedback about it.
i have a config db with a table for the language for the screen which has a column for the screen name, a column for control name and then 4 columns for different language .
when i open the form, i read that table which has the same column name for screen and then loop through the control in the screen and getting the matching entry in table and assign the language to the labels, buttons, segment control , listbox and tabpanel.
I use an approach similar to that of Richard Duke. I have a db table with unique string identifiers. The table key includes the language code, so I can translate to any language without requiring a change to the table structure. It is a simple matter to add a new language. I have a db tool that makes the translation quick and painless. I looked at the dynamic strings feature and it does look quite interesting, but since I had all the tools already, I decided to keep the database approach. It has the advantage of being very easy to maintain.
Similarly to Richard’s approach, I load language specific strings into a session array (web app) and I have a method in each form to assign the right string from the array.
And when i need to do translation for the other english, i just send the xls to someone with 2 column one english and one the other language that i need translating.
yeah, I’ve considered moving everything into a database. It might finally be time to do so.
Some of my views have several hundred strings that need to be loaded / displayed at a time. What sort of performance hit should I expect if I move everything into a DB in cases where I’ll have lots of UI to draw?