Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Load original file metadata when loading Xliff 1.2 files#29148

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged

Conversation

@eternoendless
Copy link

QA
Branch?master
Bug fix?no
New feature?no
BC breaks?no
Deprecations?no
Tests pass?yes
Fixed ticketsn/a
LicenseMIT
Doc PRn/a

At PrestaShop, we maintain our translations catalog automatically using an internal tool based on ourTranslationToolsBundle, which is capable of reverse building a MessageCatalogue by parsing the source code, and then saving it to Xliff files.

Currently, this tool is only capable of building catalogs from scratch. We are currently moving to an incremental catalog where we only add new wordings, and keep old ones even if they are no longer present in the code (because of B/C). To do that, instead of starting from a clean MessageCatalogue, we load our current catalog using XliffLoader, and use that MessageCatalogue as a base. Easy peasy. But then we found a problem...

The Xliff 1.2 standard defines a list of<trans-unit> elements within a collection of<file> elements. The<file> element has a required attribute namedoriginal, which is supposed to contain the name of the file where the wordings are used in (at least in our case it does).This attribute is currently ignored by XliffFileLoader.

This means that it's currently impossible to read a Xliff 1.2 file using XliffFileloader, and save it back to Xliff without losing data.

This Pull Request adds a newfile element to the messages' metadata (alongsidenotes,target-attributes andid). Right now, it only containsoriginal, but it could be extended to contain all the other attributes from the<file> element if needed.

This required a small change in the loader where we loop through<file> elements before fetching their<trans-unit> children, instead of fetching all<trans-unit> elements at once.

PierreRambaud, jolelievre, and mickaelandrieu reacted with thumbs up emojiPierreRambaud reacted with heart emoji
@nicolas-grekas
Copy link
Member

nicolas-grekas commentedNov 8, 2018
edited
Loading

This attribute is currently ignored by XliffFileLoader.

does it mean we have a spec violation? should we consider this a bug?

PierreRambaud reacted with thumbs up emoji

@eternoendless
Copy link
Author

does it means we have spec violation?

I guess it depends on where you draw the line regarding the scope of XliffFileLoader and MessageCatalogue. Is it just about loading the translatables and making them available for the Translator? Then it's not a bug.

In my opinion, loading metadata likenotes is a "nice to have" that actually goes beyond the scope of MessageCatalogue. It could be considered a "leak" of vendor-specific (Xliff in this case) data into MessageCatalogue. In the end I don't think it hurts, albeit for a little overhead when reading the files and a small increase in the catalogue's memory footprint.

Copy link
Member

@nicolas-grekasnicolas-grekas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

LGTM with one minor comment thanks.

Copy link
Member

@fabpotfabpot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Three things should be done before merging:

  • Take Nicolas's comment into account
  • Rebase on current master
  • Add a note in the CHANGELOG.

@eternoendless
Copy link
Author

eternoendless commentedJan 7, 2019
edited
Loading

Comment and rebase done 👍

I see that on the changelog, notes are under released versions. Should I add 4.3.0? Should I only add the note with no title?

@stof
Copy link
Member

stof commentedJan 7, 2019

this should go in 4.3.0, yes

// If the xlf file has another encoding specified, try to convert it because
// simple_xml will always return utf-8 encoded values
$target =$this->utf8ToCharset((string) (isset($translation->target) ?$translation->target :$translation->source),$encoding);
$file->registerXPathNamespace('xliff',$namespace);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I don't think you need to register the namespace again. The registration on the root element should already be enough.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I think I recall having namespace issues without it.

@fabpotfabpotforce-pushed theload-original-file-info branch frome178ff1 to4073319CompareJanuary 13, 2019 16:47
@fabpot
Copy link
Member

Thank you@eternoendless.

@fabpotfabpot merged commit4073319 intosymfony:masterJan 13, 2019
fabpot added a commit that referenced this pull requestJan 13, 2019
…es (eternoendless)This PR was squashed before being merged into the 4.3-dev branch (closes#29148).Discussion----------Load original file metadata when loading Xliff 1.2 files| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets | n/a| License       | MIT| Doc PR        | n/aAt PrestaShop, we maintain our translations catalog automatically using an internal tool based on our [TranslationToolsBundle](https://github.com/PrestaShop/TranslationToolsBundle), which is capable of reverse building a MessageCatalogue by parsing the source code, and then saving it to Xliff files.Currently, this tool is only capable of building catalogs from scratch. We are currently moving to an incremental catalog where we only add new wordings, and keep old ones even if they are no longer present in the code (because of B/C). To do that, instead of starting from a clean MessageCatalogue, we load our current catalog using XliffLoader, and use that MessageCatalogue as a base. Easy peasy. But then we found a problem...The Xliff 1.2 standard defines a list of `<trans-unit>` elements within a collection of `<file>` elements. The `<file>` element has a required attribute named `original`, which is supposed to contain the name of the file where the wordings are used in (at least in our case it does). **This attribute is currently ignored by XliffFileLoader**.This means that it's currently impossible to read a Xliff 1.2 file using XliffFileloader, and save it back to Xliff without losing data.This Pull Request adds a new `file` element to the messages' metadata (alongside `notes`, `target-attributes` and `id`). Right now, it only contains `original`, but it could be extended to contain all the other attributes from the `<file>` element if needed.This required a small change in the loader where we loop through `<file>` elements before fetching their `<trans-unit>` children, instead of fetching all `<trans-unit>` elements at once.Commits-------4073319 Load original file metadata when loading Xliff 1.2 files
@nicolas-grekasnicolas-grekas modified the milestones:next,4.3Apr 30, 2019
@fabpotfabpot mentioned this pull requestMay 9, 2019
@eternoendlesseternoendless deleted the load-original-file-info branchMarch 12, 2021 10:12
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@stofstofstof left review comments

@fabpotfabpotfabpot approved these changes

@nicolas-grekasnicolas-grekasnicolas-grekas approved these changes

Assignees

No one assigned

Projects

None yet

Milestone

4.3

Development

Successfully merging this pull request may close these issues.

5 participants

@eternoendless@nicolas-grekas@stof@fabpot@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp