Closed apourche closed 3 years ago
It was introduced by 6190db4ce64568b7ae03486bb46bdd82095c20b1, see #2218 and #2380. The Xliff specification does not define its uniqueness at all and Weblate currently assumes it's unique in the whole Xliff file. And nobody complained so far :-).
In case we would strictly follow the specification, there are no requirements on resname being unique, so it should not be used at all...
Thank you for your reply @nijel. The limit of standardization, and their interpretation ... :)
http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#resname :
Resource name - Resource name or identifier of a item. For example: the key in the key/value pair in a Java properties file, the ID of a string in a Windows string table, the index value of an entry in a database table, etc.
Without considering the uniqueness of @rename
in the <file>
, all of these examples are wrong : it becomes impossible to have a single xliff dealing with 10 different java properties file (with potential redundancy of sring).
Hopefully xliff2.0 will be more explicit on this topic :)
We will therefore modify our xliff files to make them compatible with this weblate rule...
Cordially.
ps: I very recently discovered weblate, and did not take long to choose it compared to Pootle. Great job! We will use weblate for the translation of the different components of our tool (libre software) : https://scenari.software/
Without considering the uniqueness of @rename in the
, all of these examples are wrong : it becomes impossible to have a single xliff dealing with 10 different java properties file (with potential redundancy of sring).
That's valid point. On the other side the existing implementation is there for two years and changing the behaviour would be a breaking change for existing users.
Hopefully xliff2.0 will be more explicit on this topic :)
It doesn't see to be the case - the attribute name has changed, but the description is pretty much same: http://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html#name
I don't see big enough reason to change the behaviour now, but this should be at least documented.
Thank you for your report, the issue you have reported has just been fixed.
Describe the bug
Importing an xliff file results in the determination of
Key
s by Weblate, associated with each<trans-unit>
tag. This determination seems to be based ontrans-unit /@resname
if it exists, without taking into account the current tag<file>
context. The xliff standard does not specify this rule or global uniqueness of@resname
. On the other hand, she clearly speaks of the uniqueness of@id
in the context of a<file>
tag (http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#trans-unit).So, for
@resname
, it would make sense to only enforce their uniqueness in the context of a<file>
tag.The determination of
Key
s by Weblate would become:To Reproduce the bug
Steps to reproduce the behavior:
Import Initial XLIFF file (see below) as 'translate document' component
Problem : Only one
![image](https://user-images.githubusercontent.com/25720810/100542661-a8270e80-324b-11eb-80d2-cbe311d1c80d.png)
Source string
is created for the two<trans-unit>
with same@resname
in two different<file>
tag Confirmation of the problem (bad check) :The component contains several duplicated translation strings.
Consequences of this problem: translation and export in another language produces an incomplete file, not processing the strings considered as duplicated (wrongly) :![image](https://user-images.githubusercontent.com/25720810/100542698-ef150400-324b-11eb-8a69-435c11f26904.png)
Expected behavior
The determination of
Key
s by Weblate would become:...or schould be configurable
Screenshots
Initial XLIFF file :
Server configuration and status
Thank you for your answer