Language support in template service

[palktonderAtpowelno]

Describe the solution you'd like I need the template service to support multiple languages. Having customers in multiple non-English speaking countries, the service in its current form, is of limited use to us. If the service supported language specific versions of a template, the client could provide a preferred language (either as part of the url or possibly through the accepted-language header), and get a response back with a template, a confidence (unaffected by the language) and a language indicator of some sort (either the requested language or a fallback language).

Normally all labels will need to be localized. If the service returns bound data, any dates/times and separator characters must be localized as well

[DeeJayTC]

Hey @palktonderAtpowelno , while this does not exist we had similar issues, There's a workaround that might help you and might be even better than what you ask for depending on your use case.

Have in mind, you can data-bind literarily everything in the JSON template with placeholders. Not only values. You could even use a placeholder for like sizes, widths, and colors and absolutely for all labels. I wrote one template where not only actual data but also the labels etc where all placeholders, on data-bind I just bind the labels from my resource dict for whatever language I need, same for date/time formatting, etc.

Here's an example for the data you could use:

 {
    "resources": {
        "CAPTION_INPUT_NAME": "Family Name",
        "CAPTION_INPUT_FIRSTNAME": "First Name",
    },
    "data": {
       "name": "Matt Hidinger",
        "profileImage": "https://pbs.twimg.com/profile_images/3647943215/d7f12830b3c17a5a9e4afcc370e3a37e_400x400.jpeg"

    }
}

Sample template here:

 {
    "type": "AdaptiveCard",
    "version": "1.0",
    "body": [
        {
            "type": "TextBlock",
            "text": "{$root.resources[\"CAPTION_INPUT_NAME\"]}"
        },
        {
            "type": "Image",
            "altText": "",
            "url": "{$root.data.profileImage}",
            "size": "Small"
        },
        {
            "type": "TextBlock",
            "text": "{$root.data.name}"
        }
    ],
    "$schema": "http://adaptivecards.io/schemas/adaptive-card.json"
}

[palktonderAtpowelno]

HI @DeeJayTC,

I've considered this approach, and it might solve the problem for me personally. At the same time I'm not sure this is a good approach going forward. An important question is whether having all the labels as bound data makes the templates too difficult to create and edit.

More important though is that I'm not sure this would support the natural flow for how templates are created. Especially for the public version of the template service where people might donate templates, I foresee that many will supply an "standard" English version. To support data bound labels, somebody would have to transform these templates before they could be made available. Since resources are separate from the "real" data, it would be natural that they are maintained by the template service, not by each template user. This again would mean that you'd have to support a new process for adding resources for new languages.

By using a separate template for each language, there might be less work to verify each contributed template. Also, adding a new language would just mean contributing a new template using tools already established.

[DeeJayTC]

hmm, an interesting idea could be to think about how to make templates as such localizable in general. I mean AdaptiveCards itself or the template service could have a resource dictionary for common terms such as properties related to persons, addresses, etc and maybe there's a way to just say "give me that template with en_US labels" and the service itself handles translation.

Maybe even in some way, no idea how that might look, for people to add new resources? It could be as simple as having resource files per language in the Github repo which the service can use and a new param &lang=de_de or &lang=en_UK ..etc and if nothing for the language is found it falls back to whatever is in the template itself.

hen you retrieve the template the service scans the JSON to check if there are common terms in it. EG if I have the First Name as the label somewhere and I request DE the service would replace the English term with the German term. Using some AI in the background or something like Louis.ai could actually make that a pretty powerful feature especially thinking of power automate etc. That means nothing is lost during design time, you just design the template in English and at runtime, its translated to whatever language you're requesting.

[palktonderAtpowelno]

I see that a support for common terms could potentially solve some of the challenges related to this, but there are still some pitfalls. One is the obvious one of people having to use the right label key words, the other that the localization support would be somewhat limited.

Maybe I'm just too pessimistic by nature, but I worry that many potential template contributors would shy away from the extra burden of making a template localize-able. That would mean that this burden would be put on the template service maintainers. Some (AI-)logic could be created to replace any terms found in the resource dictionary, but any terms outside of the common terms would have to be handled as well.

I just think it would be easier for people to contribute whole templates. Instead of having resource files in a folder structure based on language, actual localized templates could be found in folders base on the same kind of logic. One potential benefit of this is that localized templates can have a slightly or even vastly different layout if properties of a given language warrants that. This might be things like left to right text or languages with lengthy words or even symbols.

If you look at another issue I've reported concerning support for templates for editing, it has the same challenges on how to support a different template for the same data. Using conditionals, it might be possible to use a single template, but that would really be complex. Always using complete templates located in appropriate folders (for instance an edit folder with localized sub folders), you would have a simple and coherent way of handling all the permutations. Yes, it would definitely end up in very many templates, but it would be easy to contribute a single template.

That said, if the card/template editor made it easy to create localized versions of a template to support the flow you are suggesting, I would be fine with that.

[ghost]

This issue has been automatically marked as stale because it has not had any activity for 5 days.