[alanwww1]

Looks ok now. A few thoughts:

- Would be good to note in the translated/returned/converted strings.xml file the revision or date of the original English file it is based on. For this we could use a header entry in the source xlif file eg. like this:

Code:

<header>
  <reference>3978ce61ee897fab5daf83c345f3a8183aae0b22</reference>
</header>

(I think "reference" is an existing possible field in the xlif form)

Don't know if that would work, but I read the export function is using the source file as a template replacing the target fields and updating the updateable fields. This way we might preserve the git revision the language file is based on.

- I realized that trans-unit id and context-type="id" has the same number stored. I guess without context-type="id" we can not handle the duplicated strings right ?

- I realized that at the details tab, Transifex shows the actual English translatable strings at two places. The second one is at string ID:

Code:

String ID: Vorbis
Description: id\: 34001:context\: Sample Context
Comment: Click here to add a comment
Occurrences: -

I was not able to find another open-to-edit project to check if this is normal.

- We will of course need a re-convert utility from xlif to xml. In this case I think we should use the latest English strings file as a template, deleted of course the comments, context hints, but preserving the empty strings, empty lines, line feeds, etc. So the format of the lang strings.xml is always in sync with the English one. Should I try to make this back convert util in C++ ?

- I will make a lot of tests now, how things are working in different scenarios. Eg. the source file changes, the language strings.xml file changes at GIT AND the Transifex stored one also changes, how this would merge or overwrite. Things like this.

Thanks for the update, cheers Attila