Hi team, I believe I'm encountering a bug related to the metadata localization endpoints to retrieve and set translation (XLIFF) files: • I am retrieving a translation file via this endpoint: https://www.gooddata.com/docs/cloud/api-and-sdk/api/api_reference_all/#operation/retrieveTranslations • I then attempt to POST the same translation file and receive the below error. Note that the file was unchanged (no targets added or updated, just testing to see if the API will accept the same file it generated)

{
  "detail": "Empty segments are not allowed.",
  "status": 400,
  "title": "Bad Request",
  "traceId": "67a1f28ad6cb5b47d2f7541a633db309"
}

Can you please confirm if this is a bug? In case I'm missing something, any troubleshooting help would be appreciated - thanks!

Hi Anant, regarding the error message "Empty segments are not allowed.", this occurs because an empty XLIFF document is being posted to the child workspace. Please note that when retrieving the XLIFF document from a child workspace, it will always appear empty. This is expected behavior due to the workspace hierarchy—only parent workspaces can propagate settings to child workspaces. While the hierarchy does allow for some flexibility, such as building independent insights and dashboards in child workspaces, core components like settings, the Logical Data Model (LDM), and user structure are inherited and cannot be modified at the child workspace level. With that in mind, you will need to configure translations in the parent workspace. Once set, these translations will automatically apply to the corresponding child workspaces after enabling them.

Hi @Moises Morales - how can I translate metadata strings that are exclusively present in a child workspace?

That's a good question, currently, the translation must be transferred from the parent workspace to the child workspaces. If you have some objects/metadata strings that need to be translated in your child workspaces, then you would need to recreate them first in your parent workspace, and then translate them. Nevertheless, I do understand that this is not ideal, therefore, I will be glad to share this as product feedback on your behalf.

Thanks - please let me know if there's an ETA to support this. If metadata can only be localized for top-level workspaces that's a big gap for us, as we do have content that is unique to child workspaces

Posting any translation to the parent is technically possible, since by definition, you can inherit the translations to the child workspaces, although if there are some metadata entities that are not present in the workspace being referenced in the Xliff file, then the POST call will fail (as expected) since the API is considering it as incorrect syntax/wrong workspace; This is because there are id's tied to the entities that need to match with what you have in the workspace. In general, it should be possible to recreate them, but if you have too many of them, this could be a time consuming task. All in all, the hierarchy is meant to allow for the inheritance of settings and metadata in a cascading manner, but the translation of "orphaned" objects seems to be a corner case. In any case, as discussed before, I will be glad to submit product feedback on your behalf. Could you please specify how critical this would be for you? If the users are creating the visualizations/dashboards in their own language, could you let us know why they need to be translated/localized further? Would it make sense to take them out of the hierarchy and use stand alone workspaces where applicable?