Hi
We are using automated deployment-workflows with ExB-Dev. Since upgrading to 1.19 our deployed Experiences are no longer translated. Experience are correctly built, including all the widgets- translation files, but the index.html does not list the languages in the downloadLocales array.
Is this a bug or am I missunderstanding the workflow?
According to the Guide https://developers.arcgis.com/experience-builder/guide/experience-deployment/#automated-deployments
The locales property can be used to specify the locales to export. If this is not set, all locales will be exported.
node -e "require('./server/src/middlewares/dev/apps/app-download.js').zipApp('0', 'apptest.zip', 'my_client_id');"
The build process completes successfully and includes all widget translation files. For example, under
.../cdn/1/widgets/print/dist/settings/translations
all locale folders and translation files are present.
However, in the generated index.html, the downloadLocales array is empty. As a result, the Experience loads only in the default language (en-US), and no other locales are available at runtime.
<script type="download-options" id="download-options">{
"downloadLocales": [""]
}</script>
That does not happen if the Experiences is built / downloaded
node -e "require('./server/src/middlewares/dev/apps/app-download.js').zipApp('0', 'apptest2.zip', 'my_client_id', {locales:['en','ar','bg','bs','ca','cs','da','de','el','es','et','fi','fr','he','hr','hu','id','it','ja','ko','lt','lv','no','nl','pl','pt-br','pt-pt','ro','ru','sk','sl','sr','sv','th','tr','zh-cn','uk','vi','zh-hk','zh-tw']});"
Both resulting in an index.html with the populated downloadLocales array.
<script type="download-options" id="download-options">{
"downloadLocales": ["en","ar","bg","bs","ca","cs","da","de","el","es","et","fi","fr","he","hr","hu","id","it","ja","ko","lt","lv","no","nl","pl","pt-br","pt-pt","ro","ru","sk","sl","sr","sv","th","tr","zh-cn","uk","vi","zh-hk","zh-tw"]
}</script>
Ideally, we’d like to rely on the default behavior of exporting all available locales, rather than hardcoding and maintaining the full locale list in our automated deployment workflow.
If this is unintended behavior, I’m happy to open an official bug report — just looking for confirmation first.