8000 [2.6.x] Translation Component not properly functioning · Issue #12941 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

[2.6.x] Translation Component not properly functioning #12941

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
craigh opened this issue Dec 11, 2014 · 21 comments
Closed

[2.6.x] Translation Component not properly functioning #12941

craigh opened this issue Dec 11, 2014 · 21 comments
Labels
Translation

Comments

@craigh
Copy link
craigh commented Dec 11, 2014

It appears that the Translation Component is present, but failing to operate properly. For example if I intentionally throw an exception, I get hundreds of rows saying WARNING - Translation not found.

this was not true before the upgrade to 2.6.x

this is in use in the Zikula project and in complete dev mode at the moment. We are also have composer issues since the changeover to 2.6.x

any help is appreciated.

ping @Guite @cmfcmf
@craigh
Copy link
Author
craigh commented Dec 11, 2014

I forgot to mention that if I add symfony/translation to the composer file it removes all the errors above but then I have a duplicate install of the lib.

@MAXakaWIZARD
Copy link
Contributor

@craigh I also have hundreds of rows saying WARNING - Translation not found in WebProfiles's LOG panel even without throwing any exceptions. But translations do work anyway.

@wouterj
Copy link
Member
wouterj commented Dec 11, 2014

It seems like this is an issue with the LoggingTranslator, which was added in Symfony 2.6: https://github.com/symfony/Translation/blob/master/LoggingTranslator.php#L102-123

@aitboudad can you please take a look at this, as you created this translator?

@aitboudad
Copy link
Contributor

@wouterj Ok :)
@craigh can you provide me an example reproduce your issue ??

@craigh
Copy link
Author
craigh commented Dec 11, 2014

@aitboudad - our zikula package is quite large (compared to symfony) and the example I was using is an additional module to intentionally throw an exception (for testing). If you like I can talk you through setting that up?

zikula: https://github.com/zikula/core
breakit: https://github.com/craigh/BreakIt

@aitboudad
Copy link
Contributor

@craigh of course, just I found an exception here :p http://zikula.org/library/

@craigh
Copy link
Author
craigh commented Dec 11, 2014

hmmm. that doesn't demonstrate the problem because that install is still on Symfony 2.5.x 😉

you'll have to install the full product

@aitboudad
Copy link
Contributor

ops I don't see what's going wrong here, "WARNING - Translation not found" it's related to jms/i18n-routing-bundle (missing translate routes)

translation.WARNING: Translation not found. {"id":"zikulaadminmodule_admin_index","domain":"routes","locale":"en"} []

You can ignore logging "routes" channel if you want avoid hundreds of rows or disable logging translation.

@craigh
Copy link
Author
craigh commented Dec 11, 2014

@cmfcmf can you comment here? (your implementation of routes, etc)

@craigh craigh mentioned this issue Dec 12, 2014
Closed
@cmfcmf
Copy link
Contributor
cmfcmf commented Dec 13, 2014

The warnings are caused by the I18n-Routing bundle indeed. Here it checks whether or not a translation for a given route pattern exists:

if ($routeName === $i18nPattern = $this->translator->trans($routeName, array(), $this->translationDomain, $locale)) {
    $i18nPattern = $route->getPattern();
}

Example:

  • Route pattern: /foo/bar
  • Translation check: Is a translation for /foo/bar to %LOCALE% available?
  • YES: Okay, generate the route using the translated pattern.
  • NO: Okay, generate the route using the orginal pattern.

Because our Route patterns already are in English (and therefore need no translation to English), the NO branch is executed all the times. This then causes the warnings in the logging translator.

Maybe the I18n-Routing bundle should not try to translate the Route pattern and then check if it differs from the original pattern, but rather do something like this:

// Check if route is translated.
if (!$this->translator->getCatalogue($locale)->has($routeName, $this->translationDomain)) {
    // No translation found.
    $i18nPattern = $route->getPattern();
} else {
    // Get translation.
    $i18nPattern = $this->translator->trans($routeName, array(), $this->translationDomain, $locale)
}

Conclusion: The warnings are produced by the I18n-Routing bundle, which might need to be fixed.

@craigh
Copy link
Author
craigh commented Dec 13, 2014

I can confirm that setting logging: false removes the errors, but is obviously only a workaround.

@craigh craigh mentioned this issue Dec 13, 2014
Closed
@craigh
Copy link
Author
craigh commented Dec 14, 2014

@aitboudad - closing this ticket as it appears to be a problem with schmittjoh/JMSI18nRoutingBundle, I'm hoping they will find a fix! thank you for your attention 😄

@craigh craigh closed this as completed Dec 14, 2014
@Cedoriku
Copy link
Cedoriku commented Feb 4, 2015

Sorry to interrupt,
I am (we are) having this problem also, yet not using JMSI18nRoutingBundle, but Doctrine Translatable Plugin. The log file shows that the translator is trying to translate all the options in all the selects (choiceList) in all the forms! Having big Forms with lot of choiceList and Entity selects inputs, some pages are just crashing...

Help!

@aitboudad
Copy link
Contributor

@Cedoriku Would you mind preparing a simple example reproducing the problem ?

@Cedoriku
Copy link
Cedoriku commented Feb 4, 2015

Yes I will do that tomorrow morning ASAP.
These are just simple formTypes with choiceLists (select), and the log file shows that the Translator tries to translate every option label in the select, even for entities choiceLists that are already handled by the Translatable Plugin. So I'm not sure it has something to do with the plugin.

For each option, we get a line of that kind (don't have it in front of me right now):

Translation.WARNING.Translation not found [...] {id:"The option label", domaine:message, locale:fr}

@Cedoriku
Copy link
Cedoriku commented Feb 4, 2015

After reflexion, we're actually not sure if the crash comes from that problem, as we just encountered it. It may come from other bugs in our code, but searching about it, we found that log problem.

@Cedoriku
Copy link
Cedoriku commented Feb 5, 2015

the proper log message is:
[2015-02-04 18:40:59] translation.WARNING: Translation not found. {"id":"ROUMANIE","domain":"messages","locale":"fr"} []

@aitboudad
Copy link
Contributor

@Cedoriku So to be sure, can you disable logging to check if the problem persist or not ?

# app/config/config.yml
framework:
    translator: { logging:  false }

@Cedoriku
Copy link
Cedoriku commented Feb 5, 2015

Ok.
When Translator logging set to false, the warnings disappear.

@aitboudad aitboudad mentioned this issue Feb 10, 2015
Merged
aitboudad added a commit that referenced this issue Apr 4, 2015
@aitboudad
feature #13651 [2.7][Form][choice] added choice_translation_domain to…
fb514b6 
… avoid trans options. (aitboudad)

This PR was merged into the 2.7 branch.

Discussion
----------

[2.7][Form][choice] added choice_translation_domain to avoid trans options.

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Fixed tickets  | ~
| Tests pass?   | yes
| License       | MIT

see #12941 (comment)

Commits
-------

5a33c2c [Form][choice] added choice_translation_domain to avoid trans options.
@damijanc
Copy link

Hi I have a similar issue:

Here is my twig snippet to reproduce the behavior:

{{ form_widget(form.address, { 'attr': {
                                    'class': 'form-control phone',
                                    'placeholder':'street.and.number'|trans,
                                    'data-toggle':'tooltip',
                                    'title':'street.and.number.tooltip'|trans
                                } }) }}

This code will produce false missing translation warnings.

@xabbuh
Copy link
Member
xabbuh commented Jun 28, 2015

@damijanc Can you check if #15048 solves your issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Translation
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@craigh @wouterj @MAXakaWIZARD @damijanc @aitboudad @xabbuh @cmfcmf @Cedoriku
0