Dear all,
We would like to translate our product into various languages using Crowdin. We have an .xml-file with the ‘need-translation’-strings and we use the “id” parameter with our translation-key (e.g. “homepage.table.header.label”). We noticed that after translation, the export .xliff file from Crowdin contains new id’s (a number) and the old ids are gone.
<trans-unit id=“580” approved=“yes”> Select a condition…
Sélectionnez une condition…
Text
XPath: /xliff/file/unit[3]/segment/source
We would like to get our id back into the exported trans-unit, so the translated key gets updated automatically into our html code. I have seem a support topic within this community that showed the “resname” property in the trans-unit, that supposedly saves the original id, but I cannot find the option to include it. It does not seem to be there by default.
Does anyone know how to get the resname property? Or does anyone know a better approach for storing our “id” into the trans-unit?
How do you do the translation export? It looks like you’re using an export in .xliff option. Have you tried regular build and download from the project translation page?
By default, this way preserves file structure and updates just translation fields with localized content. It is also automatically supported by various integrations, like Github.
Here you can find an .XML sample (by the way, custom segmentation is supported for .XML files) that we support out of the box:
If switching export to basic build-download will not help please share with me (you can DM me // add it here // email us at support@crowdin.com):
your project name/id
sample source file
the translation you received from Crowdin
This way I can run some tests from my end and provide you with a reliable solution
I originally made a small error in describing the issue. The reason I said we have an xml file is because the file was recognized as such by Crowdin. In fact, it was an .xliff file, but with version 2.1, which are shown as xml and not as xliff.
I later learned that uploading .xliff version 1.2 and 2.0 work and are recognized by Crowdin as such. I found that our ids are then exported as resnames, which is what we want. We could therefore switch to 1.2 or 2.0 .
One distinction between these two versions is that 1.2 is fine with slashes in the id, whereas version 2.0 is not, as it results in an error at uploading the file. We are actually using namespaced ids (e.g. app/homepage.table.header.label), so is xliff version 1.2 then the best option for us?
Another thing I noticed while playing around with the API is that for String Translations, where we could add and retrieve single string translations, the identifier we send with the “Add String” gets lost.
The identifier will be saved in Crowdin, however, to retrieve the translation of such a string we cannot use our identifier to retrieve the translation. Instead, we need Crowdins id from the response of the “Add String” call. The retrieved translation data does not contain the identifier. Is there a way to use our own identifier in retrieving the translations, and/or to have the identifier we provided in the translation data?
Thanks for the update; it’s much appreciated. Well, things have become more interesting. In this case, we definitely need to look at your file to provide a proper solution.
You can try uploading the file using different options, this application can change file type during the import:
But if you mention this call (Crowdin API Reference (File-based)) (Get strings), yes, it uses internal identification assigned to each string during import into Crowdin, so please use it during API workflow.
.