dataverse_list_languages

List an environment's language codes (LCIDs) — which are usable, which are merely installed.

Call this before writing any localized label. provisioned is the load-bearing answer: those are the LCIDs that are actually ENABLED in this environment and therefore the only ones a LocalizedLabels entry may use (the LanguageCode on a DisplayName / Description label passed to dataverse_create_table, dataverse_create_column, dataverse_create_choice, ...). A LocalizedLabel for a language that is installed but NOT provisioned is rejected or silently dropped, so never assume 1033 (English) is provisioned — verify it.

Three unbound, zero-parameter functions are called CONCURRENTLY and their answers reconciled. THE THREE SETS CAN BE MUTUALLY DISJOINT — on the org this tool was verified against, available was [1033], provisioned was [1033], and installed_packs held 44 OTHER LCIDs not including 1033. Read each for what it literally reports and do not infer one from another:

• provisioned (RetrieveProvisionedLanguages) — the LCIDs enabled for use in this environment. THE LOAD-BEARING ONE: this is the set a LocalizedLabels entry may use, and the only one worth deciding anything from.

• available (RetrieveAvailableLanguages, container LocaleIds) — what this function reports the environment as offering. Observed live as a SHORT list that matched provisioned exactly and shared nothing with installed_packs; it is NOT "every language whose pack is on the server".

• installed_packs (RetrieveInstalledLanguagePacks) — the language packs present on the server. Observed live as by far the largest of the three and DISJOINT from both of the others. A pack being installed does not make its LCID provisioned, and this tool does not know which of them could be.

Each list is echoed exactly as Dataverse sent it (order included, not sorted) with a matching *_count. Two derived diffs are computed only when both of their inputs were read successfully, and are named after the exact subtraction they perform rather than implying one is the actionable answer: available_not_provisioned (available minus provisioned) and installed_not_provisioned (installed_packs minus provisioned). Neither is a list of languages an administrator can simply turn on — provisioning has its own prerequisites — so treat both as leads to investigate, not as a to-do list.

THE THREE CALLS FAIL INDEPENDENTLY. A function that is unavailable or privilege-gated is reported in partial_errors and the others' data is still returned, so ALWAYS read partial_errors before concluding a language is absent — a missing key means "not answered", never "empty". Only a failure of all three yields the standard {"error": true, "message": ...} envelope.

The three container property names genuinely differ (LocaleIds for the available list; the function's own name for the other two) and all three are LIVE-CONFIRMED. Each is still tried by name and then by shape (a sole list of integers), so a future change degrades rather than lies. sources reports the property each list was actually found under — check it. If a payload cannot be read unambiguously, its keys are OMITTED, normalized is false, and the untouched body appears under raw_responses; nothing is fabricated and no empty list is invented.

LCIDs are Windows locale ids (1033 = English (United States), 1036 = French (France), 1031 = German (Germany), 3082 = Spanish (Spain)); they are returned as raw integers and are not mapped to language names here.