display xliff <note> tag more visible

[transl8bzimport]

Version: 0.7.0

Originally posted by Adam:

Created attachment 796

file used for testing.

Currently the Blub gets displayed only, if hovering an item in the list. Above the translation, only the id is displayed.

It would be better to display the note, if it is available, because the id is often not as important to the translator.

Blub Titel

[transl8bzimport]

Originally posted by Adam:

Created attachment 797

displayed id and note

[friedelwolff]

Thank you for reporting this issue. What is happening at the moment is this:

• All notes are shown in the tooltips, regardless of what their origin attribute says.
• Virtaal wants to show developer comments above the source text, and comments from translators below the target text. However, in XLIFF there is no separation along these lines.

So currently we display notes with origin="programmer" above the source text and origin="translator" below the target text (simply an old convention in the way we converted some data to XLIFF), but of course other XLIFF files contain arbitrary (or no) origin attributes.

I don't see a way we can know if the note is unchangeable and from a developer or file creation tool, or editable and maybe even from the current translator (maybe in another tool). So our desired design doesn't fit quite well with XLIFF.

In theory we would like to make the notes editable (we don't support this yet). Of course, only certain ones: not the ones from the developer/tool, for example. For now, even if we can just display them somewhere, I guess it would be an improvement.

Anybody with ideas on how to address these issues, please comment to help :-)

[transl8bzimport]

Originally posted by Adam:

ah, ok, this clears things up a little.

i'm generating the xliff files by myself (eg. wrote a program for it), so it shouldn't be a problem to follow this convention (for me the issue is fixed).

it might be better to show a note with other origins, if there is no note with origin="programmer" at the place of the programmer note. I mean the following: first look if there is a programmer note, if not, look if there is something different.

naturally this is only a workaround. what would probably help, is some documentation (maybe there is already, but i haven't found it?). Anyway, this bug report will be some kind of documentation in the future. are there some other 'magic' strings in the xliff filter?

[friedelwolff]

I'm happy if the information clears things up for you, but I still consider this a bug as you reported it.

This is not really what you want, but it is the best I can find, and should probably be the home of what you want: http://translate.sourceforge.net/wiki/toolkit/xliff

We maybe need to realise that only XLIFF files exported from Pootle or confirming to the PO representation guide is likely to follow our convention, so we need to think a bit differently about this.

Does it make sense to view all comments as read only and shown above the source text?

[transl8bzimport]

Originally posted by Adam:

Thanks for the link.

Showing all comments is what I expected. But other people would probably expect to be able to edit the comments. Qt Linguist for instance displays and edits only the last comment (and looses all other ones).

As said, we generate custom xliff files and we had no prior experience with xliff, so what i say doesn't weigh much.

[Abekonge]

Does it make sense to view all comments as read only and shown above the source text?

Yes I think that would make a better solution. It could work as a sort of fallback, even though you have an ideal with different sort of comments in different places - it would make it much more useful for us.

For out workflow we extract the XLIFF with Angular 2's i18n tool, which does not source the comments. For us it would be a hassle to add comment-origins in the XLIFF afterwards.