Skip to content

[Translator] move loading catalogue out of Translator. #14671

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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

aitboudad
Copy link
Contributor

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

#14530 (comment)
It could also simplify a bunch of things:

  • lazy-loading of loaders could be implemented by implementing this interface in a lazy way (or relying of the DI feature to build the lazy implementation) instead of extending the Translator in FrameworkBundle, which would also make the lazy-loading available for people using DI+Translator outside Symfony
  • caching of catalogues could be implemented by composition instead of being in the main class dealing with loaders (which does not forbid caching the internal structures of the Translator class, which is a separate topic).

Before

$translator = new Translator('fr');
$translator->addLoader('array', new ArrayLoader());
$translator->addResource('array', array('Hello World!' => 'Bonjour'), 'fr');

echo $translator->trans('Hello World!')."\n";

After

$resourceCatalogue = new ResourceMessageCatalogueProvider();
$resourceCatalogue->addLoader('array', new ArrayLoader());
$resourceCatalogue->addResource('array', array('Hello World!' => 'Bonjour'), 'fr');
$translator = new Translator('fr', $resourceCatalogue);

echo $translator->trans('Hello World!')."\n";

@aitboudad aitboudad force-pushed the translation_loader_resolver branch 3 times, most recently from 7527f65 to 557537f Compare May 17, 2015 20:01
/**
* {@inheritdoc}
*/
public function getCatalogue($locale = null)
Copy link
Contributor

Choose a reason for hiding this comment

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

$locale may be null, which probably does not work for the other methods you're calling from here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

hmm I know about it, right now I'm not sure how to deal with it :), any thought ?
in 3.0 I would like to remove the default value:

public function getCatalogue($locale)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

fixed, I removed the default value of locale argument in TranslatorBagInterface

protected function computeFallbackLocales($locale)
{
trigger_error('The '.__METHOD__.' method is deprecated since version 2.8 and will be removed in 3.0. Rely on FallbackTranslatorBag instead.', E_USER_DEPRECATED);
Copy link
Contributor

Choose a reason for hiding this comment

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

Two things –

  1. Is that the right way to deprecate protected functions? I mean, people might override this method without calling the parent class and never get the deprecation notice. (@stof?)
  2. How can people provide their own implementation for this? Currently this is possible. That also applies to other protected methods as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

  1. I think so, if someone override public method too he can't get the deprecation notice.
  2. It depends, for example to override computeFallbackLocales method they must use custom FallbackTranslatorBag.

@aitboudad aitboudad force-pushed the translation_loader_resolver branch 6 times, most recently from b5c28e5 to 65361ff Compare May 23, 2015 11:38
@aitboudad aitboudad changed the title [WIP][Translator] move loading catalogue out of Translator. [Translator] move loading catalogue out of Translator. Jun 1, 2015
@MattKetmo
Copy link
Contributor

Hello,

I just have a quick look on this PR. It seems I also did a custom implementation of the Translator to split the different responsibilities. What bothered me was the fact that the Translator class does to much thing (file caching, resource loader, locale fallback) and I just wanted to change the cache mecanism (didn't want to cache them in php files in order to easily update them in production).

If you're insterested to have a look, here is the implementation I wrote: openl10n-translation/SimpleTranslator.php

I introduced a new MessageCatalogueLoader interface and use decoration, which is basically the equivalent of your usage of TranslatorBagInterface.

I'll have a closer look to your PR but I'm 👍 for this improvement.

*
* @author Abdellatif Ait boudad <a.aitboudad@gmail.com>
*/
class TranslatorBag implements TranslatorBagInterface, TranslatorBagIdentifiable
Copy link
Contributor

Choose a reason for hiding this comment

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

Others TranslatorBag have a named (Cache, Fallback) except this one.
I would have renamed it to ResourceTranslatorBag.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

sound good to me 👍 , done

@aitboudad aitboudad force-pushed the translation_loader_resolver branch 2 times, most recently from a646aa7 to 0a2363e Compare August 7, 2015 17:59
@aitboudad aitboudad force-pushed the translation_loader_resolver branch 4 times, most recently from 21431e3 to 70d0b85 Compare September 25, 2015 22:41
@aitboudad
Copy link
Contributor Author

ping @symfony/deciders

@fabpot
Copy link
Member

fabpot commented Sep 30, 2015

Also, tests do not pass.

@fabpot
Copy link
Member

fabpot commented Sep 30, 2015

ping @symfony/deciders

@aitboudad aitboudad force-pushed the translation_loader_resolver branch 4 times, most recently from d6d9ee1 to 07a4775 Compare September 30, 2015 18:36
@aitboudad
Copy link
Contributor Author

I added another PR #16036 which improve the performances and allows using custom provider.

@aitboudad
Copy link
Contributor Author

The failure tests is not related to this PR.

@aitboudad aitboudad force-pushed the translation_loader_resolver branch 4 times, most recently from a874893 to e53217d Compare October 1, 2015 11:52
@mpdude
Copy link
Contributor

mpdude commented Oct 1, 2015

Honestly, I have spent quite some time reviewing this and I am not sure I have completely understood this change and all its implications. My gut feeling is that this is not ready, but I find it hard to give precise technical reasons for that.

I am not in a position to decide on this, but I would really recommend to get in-depth reviews from some more other people.

@aitboudad
Copy link
Contributor Author

@mpdude what part do you think should be improved ?

@mpdude
Copy link
Contributor

mpdude commented Oct 1, 2015

Once again, I am currently working through your code :) I'll let you know!

@mpdude
Copy link
Contributor

mpdude commented Oct 3, 2015

This is a little mess because there are two code paths (with and without caching) through Translator, with several protected methods along the way and @api for all this.

@fabpot Would entirely deprecating the current Translator and adding a completely new implementation (with the same interface, of course) be an acceptable strategy?

Do we absolutely have to provide a flex/extension point for every conceivable tweak users could have made through protected methods in the past?

And, by the way, do we still have time or is 2.8 already feature-frozen?

@aitboudad aitboudad force-pushed the translation_loader_resolver branch from e53217d to 95e23d2 Compare October 11, 2015 11:46
@aitboudad
Copy link
Contributor Author

Honestly I don't see what going wrong with the current implementation. Right now I guess 2.8 already feature-frozen, so I'm going to close.

@aitboudad aitboudad closed this Oct 11, 2015
@aitboudad aitboudad deleted the translation_loader_resolver branch October 11, 2015 12:09
@MattKetmo
Copy link
Contributor

Oh, seriously! All this work for nothing?
I'd really have liked to see this merged.
I will keep my custom implemtation then.
😞

@aitboudad
Copy link
Contributor Author

@MattKetmo I haven't abandoned, I must have at least one vote from deciders to be able to merge it.
Anyway I'll try to propose it for the next release.

@aitboudad aitboudad restored the translation_loader_resolver branch October 14, 2015 18:52
@aitboudad
Copy link
Contributor Author

reopened in #16286

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants