Closed asmecher closed 4 years ago
this may break Translation::find for XLIFF files that were previously generated by this library, as they will use a md5 sum for the unit ID.
Yes, I'd add the $translation->setId($unitId);
optional. Something like:
$translations = Translations::fromXliffFile('translations.xliff', ['unitid_as_id' => true]);
And by default, set to false
.
@oscarotero, thanks, I've added that option and adjusted the tests accordingly. https://github.com/oscarotero/Gettext/pull/225/commits/3384000cbfcb9e4dd35ea039b441647423580d58
Thanks!
Many thanks for your sensible stewardship, @oscarotero!
Adds a
Translation::setId
function, with support for the Xliff extractor to call it with the Unit ID.This permits the library to better conform to xliff's uniqueness requirements (the same source text can be translated several times with different unit IDs) while still supporting PO's uniqueness requirements (the same source text cannot appear twice in the same context).
Note that this means XLIFF files converted to PO files may lose some translations that appear several times with the same source text. (This is necessary to avoid a regression of https://github.com/oscarotero/Gettext/issues/48.)
Note that I did not modify e.g. the PO extractor to use
setId
, even though it supports round-tripping XLIFF unit IDs. These unit IDs can still be read out from the comments or using\Gettext\Genreators\Xliff::getUnitID
. (This felt like the best design choice.)Note the warnings in
Translation::setId
andTranslations::find
: Translations with custom IDs (e.g. XLIFF unit IDs) may not be found by theTranslations::find
function, as it searches using IDs generated by theTranslation::generateId
function.@oscarotero, this may break
Translation::find
for XLIFF files that were previously generated by this library, as they will use amd5
sum for the unit ID.