I would like to see support for implementing multiple languages in geodatabase domain descriptions, and the ArcGIS system automatically display the appropriate language configured for the client application, similar to a resource file implementation for UI labels and other items. More and more we are supporting multi-national companies that require this ability, and the workarounds I have seen for this are an obvious hack at best.
Example Domain:
code1 -- English Description -- French Description -- French Canadian Description -- Spanish Description....
code2 -- English Description -- French Description -- French Canadian Description -- Spanish Description....
Considering the current evolution from geometric Network into the Utility Network and the new Multiplatform Service Architecture it should be relatively easy to extent the GeoDataBase Model \ Architecture to support not only Coded Domain Descriptions in multiple languages as suggested in this geonet.esri.com/ideas/7521 [Support for multiple language descriptions in Geodatabase Domains ] but also:
The new "services" could implement an (optional) parameter LanguageCode such as [List of ISO 639-2 codes - Wikipedia ] to allow the Server to respond with the appropriate encoding for the client, the response of the Service should include a ClassID and the LanguageCode to allow the client customizations to more easily handle the different "descriptions" for "classes" and "fields"
The new "clients" could (preferably) implement an (optional) language switch selector, using the Locale of the operating System would also be possible but it is probably more complicated across different platforms and shared architectures
A new "adiministration" tool for the Geodatabase could easily allow for the addition and "manual" translation of new languages in one give geodatabase; A simple XML Export \ Import Language tool would allow a very configuration and the use of external translation services (not included)
How is this still not on any road-map?
Hello dears,
I am very interested in this idea, especially in multilanguage Field aliases.
The aim is to provide fully localized application (e.g. Experience Builder app) including localized datasets (Field aliases which can be seen in Attribute table widget). Is there any other way how to achieve it than publish two completely same datasets but with different field aliases names?
Thank you,
Jan
Here are some of my Ideas on how multi language support for geodatabases could be implemented:
To “automatically” change the language the translation has to be defined somewhere.
This is not practical for fields without domains, as their text input is unpredictable, but usually domains are used anyway.
Instead of just defining description in one language, allow the creation of a “"language domain" within a domain” for defining the translations for relevant country iso codes. (Or simply add multiple Description fields in the domain tab to start with to define different languages).
Same with Field Alias names: allow setting alias names in more than one language similar to the domain behaviour.
Depending on the UI language arcgis will detect language variants and will auto switch the language for Field alias names and domain values to the respective language and fall back on the default for the ones not defined. Also allow custom changes of the alias/domain language independent of the UI.
There is now an Enhancement logged for this Idea: ENH-000156851 (You can ask your Esri Support contact to be added to this Enhancement)
@DominicStubbins Ordnance Survey are interested in this idea and it was raised on our recent call.
@Jan2 Did you ever find a way to achieve this? I am looking to do the same and really don't want to have to publish multiple versions of the same database with different field aliases names.
Thanks
Lee
Does not solve the request, but may be a suitable approach in some cases: Using Arcade to Translate Pop-Ups for Use in the ArcGIS Instant Apps (esri.com)
Hello
Are there any news on that topic or has someone found a workaround?
Thanks
Marco
What about using the Language subtypes and related subtype domains? It looks suitable in this case.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.