Re: [xliff-inline] Complex tag content

[Arle Lommel <alommel@gala-global.org>]

Hi Brian,

Don't you love email discussions where we can misread each other? I don't know if you misread me: sometimes misreading is a valuable thing anyway :-)

I don't know if I'm saying XLIFF should solve it. I rather think that this is a potentially difficult problem in general and that even if the filters solve it, they won't get a perfect solution.

But this was in response to the issue of where the best place to store markup is. There were three options. Overall I would prefer to store the markup in the trans-unit because that simplifies many downstream uses.

If the tag content is stored inline (rather than in a skeleton) it would make it easier to access the tag content when needed, but these examples showed both (a) why it is difficult (you get these gloppy messes of inline markup that you have to figure out how to display/hide) and (b) why the translator might need to get access to those gloppy messes even when the filter makes it seem that you don't need to pay attention to them.

I would, of course, argue that identifying what to show or hide should be the filters' job, but the second example shows why leaving it exclusively to the filter can be a problem as well. I doubt any HTML filter would figure what to do with that spaghetti and get it right, so the assumption would be that it was non-translatable and only manual examination would show that it is (so your point 3 is very applicable since it actually would need to be addressed even though the default assumption would have been that it was not translatable).

By the way, I'm impressed that you figured out that example 2 was malformed: I just thought it was ugly and unintelligible, but you confirmed it was a trifecta!

Best,

Arle

On Jun 14, 2011, at 17:47 , Schnabel, Bryan S wrote:

Hi Arle,

 

I didn't mean to say your examples did not solve the issue. I meant to say that I did not think your examples were not complex enough to require an elegant solution (i.e., I was side-stepping the real issue). My interpretation was that it was just a matter of asking, "does a translator need all the junk adjacent to the translatable strings for (a) context? Or (b) in order to adjust the junk based on the unique needs of the target language"? If 'yes', we then need to add the junk into the trans-unit; if 'no', we just stick it in the skeleton.

 

I assumed your examples led us the 'no' conclusion. But I now see that you meant them to lead us to the 'yes' conclusion (based on the scenario your two bullet points paint). This was not a problem with your examples - it was my misinterpretation of them.

 

To me the very interesting take-away from this thread is a philosophical one. I'll try to explain (but I'll probably not communicate this very well).

 

It sounds to me like you are saying it is the responsibility of the XLIFF spec to solve the problem of:

*difficult-to-identify-translatable-vs-non-translatable-strings-within-dense-blobs*

 

My view is that it is the responsibility of the filter/tool maker to do the difficult job of identifying translatable vs. non translatable text. Therefore it is responsibility of the XLIFF spec to provide translators with (1) a clear place to translate translatable strings; (2) enough context to translate the strings accurately, and (3) ability to make adjustments to non-translatable content in cases where the target language causes a need for such adjustment.

 

(1) and (2) seem not too difficult (although not super easy by any means). And (3) seems to be the tricky bit that I confessed to be side-stepping.

 

Sorry that I muddied it up by misreading your examples.

 

(and for the record, I love the kind of person that looks deeply at problems - finding problems is the first half of finding solutions)

 

- Bryan