Home › Forums › Cascading dropdowns › Multilingual Cascading Dropdowns
Tagged: cascading dropdown, localization, multilingual, translation
- This topic has 3 replies, 2 voices, and was last updated 8 years, 4 months ago by Alexander Bautz.
-
AuthorPosts
-
-
August 8, 2016 at 16:10 #12722
Hello Alexander,
there seems to be no way to create a multilingual cascading dropdown. Is there an easy way to support translations in dropdown fields coming from a cascading dropdown depending on the current locale?
E.g. instead of using plain text values from a lookup listLevel1 Level2
Request Reportusing something like
Level1 Level2
{“1031″:”Anfrage”,”1033″:”Request”} {“1031″:”Bericht”,”1033″:”Report”}Thanks for looking into this
Dirk
-
August 9, 2016 at 20:09 #12759
Hi,
While adding support for a JSON string input in the Cascading dropdown solution is fairly easy, it would work only in NewForm and EditForm. List views and DispForm would not be translated using this approach. I guess you plan to save the “default language” as a string in the field, and not save the JSON string?You could use other code to translate the choices in DispForm and List views, but I’m not sure it’s worth the effort as other input in the form (like text) wold be in only one language.
Alexander
-
August 15, 2016 at 16:40 #12844
We have managed to display translated texts for choice fields in all forms Newform, DispForm and EditForm using your localization script (https://spjsblog.com/2013/02/07/translate-choice-column-values-in-newform-dispform-and-editform/) within the custom JS, and leave the default language in list views, which was acceptable for clients.
E.g. var translationSettings = {“cmTermExtension”:
{“None”:{“1031″:”Kein”,”default”:”None”},
{1 Year”:{“1031″:”1 Jahr”,”default”:”1 Year”},
“2 Years”:{“1031″:”2 Jahre”,”default”:”2 Years”},…Since the only purpose of the list is to act as a lookup list for DFFS Cascading Dropdowns, there would be no need to support a localized list view for the lookup list itself. Being able to select a localized value and then store the default language in the target field could be sufficient.
It’s really sad that SharePoint’s localization features are far from perfect, but this scenario would help in all cases where end users expect to see a fully localized form to add data, and where people working with the data would only work in one default language (which is true in our case).
So I don’t know if this request is common enough to be useful for others too, but if it is really easy to support international JSON strings, we could definitely use it.
PS: The only real solution to fully localize “choice fields” that we came up with, was to use a multilingual managed metadata field. Being able to use a localized taxonomy in DFFS is maybe worth a thought, but all we can tell is that handling of managed metadata fields is quite complex.
So let me know your thoughts.
Thanks a lot
Dirk
-
August 20, 2016 at 10:15 #12914
I have added a new option to use JSON string objects in the datasource – check out the “incremental release” here
You find a readme file in the zip-file.
Let me know how it works out.
Alexander
-
-
AuthorPosts
- You must be logged in to reply to this topic.