Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
628: Support XLIFF tags in android imports. #636
That's because the current code encodes all less than signs as HTML entities (see https://github.com/GlotPress/GlotPress-WP/blob/develop/gp-includes/formats/format-android.php#L164). It will get "worse" once we include double quotes in the escaping as well.
The current code assumes that only displayable text is in the export.
I would think that with the current GP workflow that the originals import would contain the xliff tag and then the translators would remove it from the translation. That would maintain the current assumption about the output.
We could do a similar hack and after we've encoded the less than signs, decode any "<xliff:g"'s that exist, but that will become much more cumbersome with the double quote escaping happening.
In an ideal world, when we imported the originals we'd parse the xliff tag and store the metadata somewhere else so the editor could "enforce" the non-editable text in the translation.
Ok, I've updated the PR to change the behaviour of the xliff tags.
The previous code simply kept them as part of the imported text, the new code instead strips them out and adds a comment to indicate what should be done.
For example, if you import an original with the following string in the xml file:
the importer will create this original:
but also add this comment to the translation:
I haven't tracked down why the comment doesn't wrap but instead forces the entire meta area to appear below the original/translation, but that should be just a css rule somewhere (any suggestions on that one would be appreciated).
But, most important, android translated strings.xml usually contain xliff node if source string.xml does.
Example online (from Android platform framework base source):
This means that translations can contains xliff:g with some differences.
In this example, the '%2$s' is present in all translations, but it can be 'wrapped' into xliff nodes with different id value, depending on translation.
So I think xliff nodes should be kept when exporting any files, may it be the reference language, but also per language.
This is my understanding of the Android xliff usage. @toolstack What is your opinion about that?
Thanks a lot!
@ocean90 that example is not really any different than any of the others, just what text is not to be translated.
@pdalfarr No doubt you can export the xliff's again, but they're never used by an Android app from my understanding, they're there only to let translators know what not to translate. They would never change based on which language you were translating to.
If you're going to use a centralized tool like GP to do the translation, then you would import the xliff's as part of the originals, then only do the exports when you're ready to release the app. You wouldn't let your contributors directly edit the xml files but instead direct them to contribute to your GP install.
This is caused by a fundamental difference between the workflows for po/mo files (which contain both the original and the translation) and Android XML files, which only contain the translation.
As GP is designed around several assumptions based on the gettext standard, there's a bit of shoehorning to get Android or other formats that don't share the same assumptions to work in GP.
Storing the xliffs and re-exporting them would require significant changes to GP.
@ocean90 Thanks for the reply.
I understand your point of view, and "Storing the xliffs and re-exporting them would require significant changes to GP" close the discussion then ;-)
The new functionality to take xliff into account is really great. The additional one I just mentioned was just 'cherry on the cake'. Without it, the cake is still really tasty :-)
PS: I tested your WordPress GP Require Login plugin: it's working fine. Thanks!
I've updated the PR to fix the css issue as well as add some additional test cases and support single quote attributes in the xliff tag.
@ocean90 when you get some time take a look at the css "fix" it changes the behaviour of the translation row a bit but I think it works better overall.