Xliff in android xml files

[r3gis]

Hi,

I've just switched my opensource android project to Transifex.
I was actually looking on doing things myself using django (I'm big fan of django) when I found that it was already done with a lot of cool features :).
So first of all thanks alot for this project : it saves me a lot of time :)

Now, my question/bug report :
In my android project I have some translations that uses xliff.
As far as I've read from the bug tracker xliff is supported, but I think it is only for standard xml files.

Here what I observe with my android project.
http://code.google.com/p/csipsimple/source/browse/trunk/CSipSimple/res/values/log_strings.xml?r=1163
Here's problems I can observe :
* it is imported on transifex but adds some extra quotes for the text that after a xliff tag
* when I pull/export the file doesn't contains anymore the xliff namespace import
* when I pull/export the xliff tags are wrapped by quotes and all quotes inside xliff tag are escaped

Is there a preferred way to use xliff in android files? Or is it a bug?
If you want, I can get time I'll have a look on the transifex code related to android import/export and propose a patch if that's a bug and not something I do wrong ;).
For now I'll separate transalations that uses xliff into another file.

Again big thanks and congrats for Transifex :)

[r3gis]

Another point :

&lt; are converted into < which also breaks translation files

[r3gis]

And another one :

unicode char \u2026 that are advised to replace "..." in android (by androidlint) are escaped as well and becomes \\u2026

:)

[r3gis]

Oups... my bad : for the \\u2026 and for the additional quotes the culprit is a tool I used previously, not transifex.
Remains the problem for xliff tags only.

Sorry for the spam ;). I raise my remark as I discover it to forget nothing ;)

[rtnpro]

Hi,

On Apr 7, 4:45 pm, r3gis <r3gis...@gmail.com> wrote:
> Oups... my bad : for the \\u2026 and for the additional quotes the culprit
> is a tool I used previously, not transifex.
> Remains the problem for xliff tags only.
>
> Sorry for the spam ;). I raise my remark as I discover it to forget nothing
> ;)

I was also wondering the same thing. I went through the Android
localization documentation and strings documentation. The contents of
<string> element should be some text as mentioned here
http://developer.android.com/guide/topics/resources/string-resource.html#string-element.

Thanks,
Regards,
rtnpro

[r3gis]

Hehe, this documentation doesn't say everything ;)

I've read a lot of the core Android source code, and actually some of my resources came directly from official android source code.
For example
https://github.com/android/platform_packages_apps_mms/blob/master/res/values-af/strings.xml
Is the stock strings resource of the android mms package. And as you can see, there is some xliff included !
Almost *all* strings.xml files of stock android apps contains xliff : Stock settings, phone, contact, music, email apps contains xliff namespace and xliff usage.

I agree that xliff is maybe not necessary in my case (and I can get rid of it easily).
But since it's supported by android and actually used in all stock applications, it's valid. So should probably be supported, at least to not have a limitation for existing projects that follow the way google guys develops their apps and uses string resources ;).
So I think that it has not a critical priority (few developers knows about that), but would be very nice to have. For example if some Cyanogen fork would like to manage internationalization using Transifex, it will be critical problem ;).

For me, the more annoying point now (once xliff things isolated) is the point about the &lt; that becomes < . I have no way to workaround that for now and have to revert this part each time I pull. It's only one line in my translations but it's pretty annoying to have to care about that each time. (the good point is that the app doesn't build if there is a < instead of a &lt; so I can quickly know if there is something wrong after a pull from translation ;) ).
And this point is in the doc : http://developer.android.com/guide/topics/resources/string-resource.html#FormattingAndStyling in section "Styling with HTML markup"


Thanks,
And sorry again for the previous spamming. I was so excited to use something that uses django in my opensource project that I was in flooding mode (I hate developing in java... but well... for android I have to...)

[Ratnadeep Debnath]

Hi,

On Sun, Apr 8, 2012 at 2:35 AM, r3gis <r3gi...@gmail.com> wrote:
> Hehe, this documentation doesn't say everything ;)

Truly said :)

> I've read a lot of the core Android source code, and actually some of my
> resources came directly from official android source code.
> For example
> https://github.com/android/platform_packages_apps_mms/blob/master/res/values-af/strings.xml
> Is the stock strings resource of the android mms package. And as you can
> see, there is some xliff included !
> Almost *all* strings.xml files of stock android apps contains xliff : Stock
> settings, phone, contact, music, email apps contains xliff namespace and
> xliff usage.
>
> I agree that xliff is maybe not necessary in my case (and I can get rid of
> it easily).
> But since it's supported by android and actually used in all stock
> applications, it's valid. So should probably be supported, at least to not
> have a limitation for existing projects that follow the way google guys
> develops their apps and uses string resources ;).
> So I think that it has not a critical priority (few developers knows about
> that), but would be very nice to have. For example if some Cyanogen fork
> would like to manage internationalization using Transifex, it will be
> critical problem ;).

Yes, such <xliff> tags are supported by Android, Transifex should also
support them.

> For me, the more annoying point now (once xliff things isolated) is the
> point about the &lt; that becomes < . I have no way to workaround that for
> now and have to revert this part each time I pull. It's only one line in my
> translations but it's pretty annoying to have to care about that each time.
> (the good point is that the app doesn't build if there is a < instead of a
> &lt; so I can quickly know if there is something wrong after a pull from
> translation ;) ).
> And this point is in the doc :
> http://developer.android.com/guide/topics/resources/string-resource.html#FormattingAndStyling
> in section "Styling with HTML markup"

This is an issue. We'll fix this as soon as possible.

>
> Thanks,
> And sorry again for the previous spamming. I was so excited to use something
> that uses django in my opensource project that I was in flooding mode (I
> hate developing in java... but well... for android I have to...)

Hehe, that's alright ;)

--
Ratnadeep Debnath,
Software Developer & QA, Transifex
GPG Fingerprint: 033C 8041 A0E9 CDBA 2E02  B785 2119 5486 F245 DFD6

[Miroslav Suchý]

On 04/07/2012 12:29 PM, r3gis wrote:
> As far as I've read from the bug tracker xliff is supported, but I think
> it is only for standard xml files.

Not even standard ones. Sadly.

XLIFF support is very new. I wrote it 9 months ago. Just by reading
XLIFF specification and looking at the code of Transifex. I was not able
to make running developer setup of Transifex, so it was written nearly
from top of my head.
But Transifex start using new resource backend so my work had to be
fixed anyway. Ratnadeep take it and rewrite it and put there some
enhancements.
So right now simple XLIFF documents works. But XLIFF standard is quite
comprehensive and as soon as you will start using namespaces, groups
etc. bugs will start appearing. I reported some and Ratnadeep fixed them
(very good work indeed).
If you find some problems, I think best you can do is to report them here:
https://getsatisfaction.com/indifex/problems/common
one issue one report.
And I'm sure that if you attach patch which fix that issue, then it will
make things faster.
--
Miroslav Suchy
Red Hat Satellite Engineering

[Dimitris Glezos]

2012/4/10 Miroslav Suchý <msu...@redhat.com>:

> If you find some problems, I think best you can do is to report them here:
> https://getsatisfaction.com/indifex/problems/common
> one issue one report.

It's also worth noting that we plan on releasing the parsers as a
separate library with its own test suite to make it easier for patches
to flow in.

-d

--
Dimitris Glezos
Founder and CEO, Transifex
US Tel: +1.650.440.2308

Social Localization Crowdsourcing
http://www.transifex.com/ -- http://angel.co/transifex

[r3gis]

Dimitris Glezos wrote :

2012/4/10 Miroslav Suchý:

> If you find some problems, I think best you can do is to report them here:
> https://getsatisfaction.com/indifex/problems/common
> one issue one report.

It's also worth noting that we plan on releasing the parsers as a
separate library with its own test suite to make it easier for patches
to flow in.

Ok, thanks for the great support ! and for the precisions.

About xliff in android, as far as I can tell, google engineers only uses the group feature. So even a very basic support should be enough for android xml files to cover 99% of androids apps.

Regards,
Régis