msoutopico

Here comes an update: this problem doesn't seem to happen (anymore) in file paths in search results (Search dialog) and in matches (Matches pane), however it still happens in the "Found in" dialog that appears to show location of hidden matches when they are identical to the one displayed. SHould this ticket be re-opened or shall I create a new one? e.g.

I think that's all. I provided here all the relevant info I could gather.

In case it helps, the bug was fixed in our own fork, as far as I can tell.

Hi Damien. I think by “orientation” you mean text alignment. That is really not that important, RTL is better right-aligned but it’s not an issue if it’s left-aligned, just as it’s not an issue to right-align LTR text. What matters here is the direction of the text, which must be RTL for languages using the Arabic or Hebrew scripts. I hope this helps and thanks for your efforts.

Option to give or revoke full writing access to team project users

Add notes as <note> in target XLIFF file

For the record, this issue happened recently again in another project. The enforced match that the translator saw and the reviser approved was not the translation used in the target document (generated with OmegaT on console mode in the server). As we only revise in OmegaT, nobody noticed the discrepancy except the client looked at the target file after delivery. Probably this happens more often than we think but the problem just go unnoticed. Backporting would entail changing the logic of how x-auto...

This is resolved on the Okapi plugin end on ticket okapi-plugin#37. I think this ticket can be closed (I don't have permissions to update it).