-
-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Duplicate translations with different XLIFF unit IDs are not maintained #224
Comments
@oscarotero, I am happy to code up a solution, but as with #220 I'd like a little guidance about the best option because I'm not familiar with how the translation IDs are used elsewhere in the library. |
Mmm, I don't know how to solve this. On the one hand, the unit id is not unique, on the other hand, the source is not unique either. I guess the uniqueness of a translation in Xliff is a sort of combination of unit id + source? |
I don't think XLIFF has any requirements of uniqueness involving the source text. The XLIFF 2.0 spec does talk about uniqueness of IDs, but that's pretty much it. For example, by my read, each unit (= I think it'll be necessary to inform the mechanism for ID generation (currently the static |
In gettext, we have the following structure:
Right now, the equivalent in Xliff would be:
A possible solution could be to get the # XLIFF_SOURCE: source-element
msgid "unit-id"
msgstr "translation" |
@oscarotero, but wouldn't that be a radical departure from either/both the PO and XLIFF standards? My understanding of .po files is that |
I was thinking in how to use these translations in the html templates. Using the unit-id as the msgid, you can get the translations by that id: <h1><?= __('unit-id') ?></h1> But, at the same time, if you scan this template searching for gettext entries, this translation will have "unit-id" string as the original untranslated string. So, finally, we can assume that the unit id and the source are the same thing (or at least, share the same purpose: to identify a translation). I don't know, it's hard to fit the Xliff format into gettext without lossing data. I'm open to other possible workaround. |
@oscarotero, we already have large parts of an internationalization toolset in place, including a caching layer that'll go in front of Gettext and tools in our PHP code and Smarty templates for getting translations. What I'm hoping to use Gettext for is specifically its XLIFF load/save features -- i.e. just the XLIFF extractor and generator, but not the We're introducing Gettext in an attempt to move from our own bespoke XML files to the XLIFF standard. We're using symbolic IDs instead of English-language text in our source code, hence the use of the unit ID in XLIFF. Our goal is to facilitate the use of commodity translation tools like POEdit and Weblate, thus we need the XLIFF content to be usable within those tools (and I think using I think the purpose of
|
Translation has the The right solution could be add a Maybe we could add the And because Xliff generator use this method to generate ids, include the warning here too. |
Thanks, @oscarotero, I submitted this according to the suggestions you made: #225 I think there is still one issue to resolve, as noted in the PR comment. |
#224 Allow for setting custom ID to avoid translation clobbering
From your earlier comment:
My reaction was...
...but it turns out many projects actually do use PO files written this way (with symbolic IDs in the Just documenting something I learned in the hopes it'll be useful to someone else :) |
I'm maintaining XLIFF tools for a free site: https://xliff.tools/ Does the "ID Replacement" tool do what's required? If not, I'm interested in learning more about the issue and possibly implementing it. Thanks! |
This is a knock-on issue from #220. (I hope you won't regret adding that already!)
An XLIFF file may contain several units with the same translation content... (silly example but you get the point)
However, when loading the translation from the XLIFF file, only one gets loaded into
$translations
. This is because the two will have the same ID, based only on the source text ("am"), without considering the unit ID.Thus trying to save the loaded XLIFF again will drop one of the two entries.
The text was updated successfully, but these errors were encountered: