Bug in XLIFF download of plurals

When downloading an XLIFF file (whether via UI or API), the plural forms contain the singular source text (the translation, where it exists, is correctly in the plural). This appears to happen in some files, but not others.

As a workaround until this bug is fixed, the pluralized:yes filter can be used to doublecheck these strings in the UI.

Hello, this is Sandy from the Transifex support team. To investigate this further, can you please share with me the URLs of two resources? For the first resource, please share one where you see this issue, and the second should be a resource where you do not see this issue. Many thanks in advance for considering my request.

Hello Sandy,

Thanks for getting back to me. Here is the only resource where I have observed this problem so far (with the offending string selected; in this string, the singular source is exported twice):
https://www.transifex.com/meganz-1/desktop-en_nz/translate/#de/translationsourcets/441950362?q=key%3AWe're+text%3A’backing+up+your+folder.+The+time+this+takes+depends+on+the+files+in+this+folder.’

And here is one of many resources that work fine:
https://www.transifex.com/meganz-1/android-40/translate/#de/strings?q=key%3Aphotos_album_delete_confirmation_description

Let me know if you need anything else.

Kind regards,
Endre

Hello, thank you for your reply; I reviewed your files and found what is happening; the issue is specifically on .ts source files.

Here is an example of a .ts file:

As you can see, the source is a single string ("You have %n new video(s) "), whether the translation contains plurals or not. Source pluralized strings are in “numerusform” tags; the first one (“You have %n new video”) is for “single”, and the second one (“You have %n new videos”) is for “other”.

When the translation file is downloaded as an XLIFF file, the content looks like this (NOTE: singular and plural are dummy translations):

As you can see, the source elements (in both trans unit elements 4[0] and 4[1]) in the XLIFF file are filled with the source element ("You have %n new video(s) ") from the .ts file; in theory, this behavior is correct.

To have the XLIFF file the way you want (this is also the way it makes sense, in my opinion), source elements in the XLIFF file should be filled with “numerusform” elements from .ts file, “You have %n new video” should be the source of trans-unit id=“4[0]”, and “You have %n new videos” should be the source of trans-unit id=“4[1]”. Something like in the image below:
Screenshot 2023-02-10 at 15.51.42

I communicated this to our engineering team to identify if this is a bug or expected behavior; I’ll keep you posted as soon as I receive information about this matter, many thanks for bringing this to us.

Hello, This situation was registered as a bug; our product team will work on having this fixed as soon as possible; I’m sorry for the inconvenience this issue caused you. I’ll be following this issue closely, and I’ll let you know when it is fixed. Thank you for bringing this to us.

Thanks for the update, Sandy, I greatly appreciate both the clear communication and the fact that the issue is being dealt with.

Kind regards,
Endre

Hello Endre!

This issue was handled; please give it a try, download an xliff file, and see the file contains all the pluralized translations!

Dear Sandy,

I confirm that the problem in ts files is solved – many thanks for your effective help!

Kind regards,
Endre

1 Like

I’m glad to read this! Thanks for letting us know the fix was successful!

Regards,

Sandy