[Languages] - Endpoint to relate availableLanguages i.e. "en" to a language ie. "English"

[xIrusux]

This could just give me all the available languages and their "display name" / or it could give a list of keys i.e. "en" with display values "English".

Lets discuss / see what its like in the classic ui

[martineiber]

You could use the /api/settings Endpoint.

There you get all validLanguages and also the Display Names

That should solve this issue?

[xIrusux]

@martineiber this is what I am doing currently but was informed there is a difference as those are specifically validAdminLanguages and could differ from the options in the domains. I would need an array that really encompasses all possibly available locales. Separate from the admin

Let's chat if that helps!

[xIrusux]

@martineiber
I'm afraid this set up does not work with what we are showing in the frontend.

The ideal scenario here would be to have a "look up" for the the locales i.e "en" -> "English", "de" -> "Deutsch" in the settings API to connect them to a Language.

The POST /pimcore-studio/api/translations/list API call should therefore return a list of all available locales for each translation domain. for example: "locales": ['en','de'....].

If it is not simple to create a "global look up", we have to include the "Language" string i.e. "English" etc. in the Response of API calls that relate to languages. (for example Website Settings)

The Website Settings API call
POST /pimcore-studio/api/website-settings
also needs to return a list of locales that are editable here.

[xIrusux]

@martineiber @markus-moser
My notes from our call for where to go from here

1. Return table for 'locale <> language' of all possible languages that will serve as a "lookup"
2. on POST /pimcore-studio/api/translations/list API call return a boolean for whether the translated domain uses frontend or backend translations
3. allowedLanguagesForViewingWebsiteTranslations and allowedLangaugesForEditingWebsiteTranslations to be array of locales for consistency