This seems to have become a series, as Microsoft adds features to SharePoint JSON formatting.  The previous installment is here.  A week ago, Microsoft released a new @UIlcid token, which corrects the problem that I discussed in the previous post.  This time, this token is the actual current language of the site, unlike the @lcid token that was available before.

So unlike the earlier post (read it now) using “@UIlcid” rather than “@lcid” resolves all the issues about matching the Language and the Locale.  The example is very similar to the previous post, and the effect is the same, just use “@UIlcid” (Note: it’s case-sensitive) rather than “@lcid” and you can replace the display of field values including choice columns with the translation without changing the value that is stored.

Does it apply to other places where the value appears?  Yes!  Well, most of the time.  Does it work in “new” and “edit” panes?  Yes!  Below, both the selected and unselected values are translated.

Does it work for “Type to filter”?  No.  The filtering mechanism knows nothing about the translations.  For that you would need to use multilingual managed metadata instead; it knows about translated values and can filter by them, and now column formatting works on that field type.

Does it work in grid view?  Yes it does!

Does it work with Multi-select choice fields?  No, but it could with a little extra effort.  You would simply have to use forEach and loopIndex to go through the values and translate them individually, selected or not.

As you may have guessed, automatically translating choice columns is an upcoming feature of PointFire 365, with lookup columns to follow.

About the Author:

You can catch Martin at ESPC22 at the PointFire booth.

Reference:

Laplante, M. (2022). Language-dependent JSON column formatting: this time it’s the @UIlcid token. Available at: https://blog.icefire.ca/blogs/post/language-dependent-json-column-formatting-this-time-it-s-the-uilcid-token [Accessed: 1st November 2022].