The Jade 2025 release focuses on modernising the developer experience and helping you build faster, smarter, and more scalable applications.
We are currently experiencing many challenges dealing with multiple locales, in particular with languages requiring Unicode character sets.
Our main development environment is ANSI because we have customers that have ANSI systems. We have some customers whose languages require Unicode systems (Thai, Chinese, Croatian). So the issue we have at the moment is that when we extract code from development and deploy to customer systems, we overwrite the translations.
We are looking at resolving this by having a Unicode copy of development which we regularly update and taking Unicode extracts from there. When we update from the ANSI system, we would need to extract the translations beforehand then reload afterwards.
This is a messy solution and I suspect we may run into issues when trying to load code changes for forms without taking translations or loading form translations without taking code changes. Ideally it would be great if there was an easy way to just extract/load all translatable strings (including those used in forms) without taking anything else.
Or is there a better way we could be handing this?
On a similar note, we currently have seven different locales we are using and if, for example, we move a control on a form then we have to manually go and make the same change in seven different places. It would be good if there was a way to apply changes like this to all locales, because for the most part we are only really interested in translating text.
Guest
We also have to support multiple locales which require Unicode so we took the following approach:
When we deployed to the first site which required Unicode, we made the decision to move all our systems to Unicode, even for those in English language countries that don't technically require Unicode. We used the Jade supplied tools to convert our many existing Ansi production systems to Unicode as part of our next major release. This included migrating our development environment to Unicode. Taking this approach removed any complexities from trying to support both Ansi and Unicode production systems. It also meant that users in English locales had no issues when they needed to reference names or places which required Unicode characters in their data entry.
We also made the decision that we were only going to translate the captions/text and not have a different form definition for the various different locales we support. We therefore use the Single Definition, Multiple Translations forms management style. This allows us to paint a single form definition, with captions/text set to $TranslatabelStringName. This means that when we move controls around, this is reflected for all locales, and we don't have to make the same change once for each supported locale. In fact, we only have English NZ locale defined in our development system, and our deployment mechanism adds all supported locales during the deployment process. This has the added benefit of reducing the size of our scm/ddx files when shipping new releases of our software. Although, it does mean that the person doing the translation has to fit their translation into the same width as the original English version of the caption. For this reason, we try to allow significant white space around the captions in the English version of our forms. We also try to avoid pluralised captions, for the benefit of the translators in Indonesia.
We wrote our own "Translation package schema" which stores all the translatable string definitions in our own objects in that package schema. We update the package schema with any new or updated strings as part of each release. Then, we have forms within the admin area of our application to allow admin users to translate our package schema definitions of the strings as appropriate for their locale. Once they have updated the definitions, they can click the "Deploy" button in our admin forms to deploy those updates to the actual JadePlatform translatable string definitions "on-the-fly". This means we have no need to retain a master copy of all the translatable strings, and we won't lose or overwrite any of their translations when we deploy our releases. Interestingly, this facility is also used by our English locale users to translate some of our captions/text into the terminology used by that organisation.
Using the above has made it much easier for us to handle being in several locales which require Unicode versions of the JadePlatform, without adding a lot of overhead to our day-to-day development processes. There was an initial cost to writing the translation package schema, but that was a one-off cost that has long since been recovered by the reduced amount of work required during development. This was especially the case when we moved to the Single Definition, Multiple Translations forms management style, as we no longer had 6+ versions of the form to edit when moving controls around or adding new controls, and adding even more locales no longer increases the workload when editing existing forms.
Hope that helps.
Cheers,
BeeJay.