8000 Make language file name configurable in translation component · Issue #27644 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content
8000

Make language file name configurable in translation component #27644

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.

Sign up for GitHub

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

Jump to bottom
Closed
DanielSiepmann opened this issue Jun 19, 2018 · 4 comments
Closed

Make language file name configurable in translation component #27644

DanielSiepmann opened this issue Jun 19, 2018 · 4 comments
Labels
Feature Translation

Comments

@DanielSiepmann
Copy link

Description
In v4.1.0 the file name of XLIFF files is linted to contain the language as suffix. So locallang.de.xlf would be valid, while de.locallang.xlf would not be valid.

That might be fine for Symfony projects. But there are other projects out there also using XLIFF for translations. In TYPO3 CMS for example the order is different. To still use the translation component to validate XLIFF files for other projects, like TYPO3 CMS, I would suggest to make this configurable. By keeping the old behaviour as default this would be a non breaking change.

As a benefit the component can work as a Linter in further projects and might get further contributions.

Example
An example call with configurable position might be:
php lint:xliff --filename-language-position prefix <filename>

I would be happy if this change sounds reasonable. It shouldn't be a huge thing.
@javiereguiluz
Copy link
Member

Do you know if this is a common practice in other popular projects ... or is just a TYPO3 practice? Thanks!

@DanielSiepmann
Copy link
Author

I didn't check further projects. I'm coming from TYPO3 CMS and only know that it's common there.
It would be no problem to provide a Pull Request with this change.

If it would not be added to the component, what other possible ways do I have, except managing a fork?

@javiereguiluz javiereguiluz mentioned this issue Jun 20, 2018
Merged
@javiereguiluz
Copy link
Member

Instead of adding a config option, in #27655 I'm proposing to accept both filename formats. Now let's wait and see if the Symfony Core team accepts it. Thanks!

@DanielSiepmann
Copy link
Author

Big thanks :)

fabpot added a commit that referenced this issue Jun 25, 2018
@fabpot
feature #27655 [Translation] Added support for translation files with…
0dcf111 
… other filename patterns (javiereguiluz)

This PR was squashed before being merged into the 4.2-dev branch (closes #27655).

Discussion
----------

[Translation] Added support for translation files with other filename patterns

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #27644
| License       | MIT
| Doc PR        | -

This implements the #27644 feature request in case we accept it.

My vote is 👍 because the changes required are tiny and the resulting code is even more robust thanks to the new `preg_match()` call.

Commits
-------

0ee912d [Translation] Added support for translation files with other filename patterns
@fabpot fabpot closed this as completed Jun 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Feature Translation
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@fabpot @javiereguiluz @DanielSiepmann
0