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

[Translation] Collect original locale in case of fallback translation#32925

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
fabpot merged 1 commit intosymfony:3.4fromdigilist:profiler_fallback_locale
Sep 27, 2019

Conversation

@digilist
Copy link
Contributor

Before, it collected the fallback locale that was used to translate a key. But this information is confusing, as it does not reveal which translation key is missing in the requested language.

So I'd like to propose to track the "requested" locale instead, so that the Symfony profiler gives me the information in which locale the key is missing instead of which locale was used as a fallback.

QA
Branch?3.4
Bug fix?yes
New feature?no
BC breaks?yes?
Deprecations?no
Tests pass?yes
Fixed tickets
LicenseMIT
Doc PR

In principle, this change is a BC break, but imho also a bug. It's really confusing when the Profiler tells you that it uses a translation fallback for an ID and locale that is actually translated. Took some debugging so recognize that this fallback came from another locale. If you think it's better to target 5.0, I'll update the PR.

@ro0NL
Copy link
Contributor

would it be useful to keep this information under e.g.fallback_locale for this state? And adjust the table to show both in this case.

To further clarify i think the panel title should beDefault locale actually

digilist reacted with thumbs up emoji

@digilist
Copy link
ContributorAuthor

That's a good idea and I made the adjustments :)

@digilistdigilistforce-pushed theprofiler_fallback_locale branch from29f6749 tod369be8CompareAugust 11, 2019 12:34
Copy link
Contributor

@ro0NLro0NL left a comment

Choose a reason for hiding this comment

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

im for 3.4 👍

@fabpotfabpotforce-pushed theprofiler_fallback_locale branch fromd369be8 to5564e14CompareSeptember 27, 2019 05:57
@fabpot
Copy link
Member

Thank you@digilist.

fabpot added a commit that referenced this pull requestSep 27, 2019
…translation (digilist)This PR was squashed before being merged into the 3.4 branch (closes#32925).Discussion----------[Translation] Collect original locale in case of fallback translationBefore, it collected the fallback locale that was used to translate a key. But this information is confusing, as it does not reveal which translation key is missing in the requested language.So I'd like to propose to track the "requested" locale instead, so that the Symfony profiler gives me the information in which locale the key is missing instead of which locale was used as a fallback.| Q             | A| ------------- | ---| Branch?       | 3.4| Bug fix?      | yes| New feature?  | no| BC breaks?    | yes?| Deprecations? | no| Tests pass?   | yes| Fixed tickets || License       | MIT| Doc PR        |In principle, this change is a BC break, but imho also a bug. It's really confusing when the Profiler tells you that it uses a translation fallback for an ID and locale that is actually translated. Took some debugging so recognize that this fallback came from another locale. If you think it's better to target 5.0, I'll update the PR.Commits-------5564e14 [Translation] Collect original locale in case of fallback translation
@fabpotfabpot merged commit5564e14 intosymfony:3.4Sep 27, 2019
This was referencedOct 7, 2019
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@fabpotfabpotfabpot approved these changes

@nicolas-grekasnicolas-grekasnicolas-grekas approved these changes

+1 more reviewer

@ro0NLro0NLro0NL approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

3.4

Development

Successfully merging this pull request may close these issues.

5 participants

@digilist@ro0NL@fabpot@nicolas-grekas@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp