8000 Make Translator::getLocale() behave the same as TranslatorTrait::getLocale() by jschaedl · Pull Request #38230 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

Make Translator::getLocale() behave the same as TranslatorTrait::getLocale() #38230

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
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 0 additions & 1 deletion src/Symfony/Component/Translation/Tests/TranslatorTest.php
Original file line number Diff line number Diff line change
Expand Up @@ -510,7 +510,6 @@ public function getInvalidLocalesTests()
public function getValidLocalesTests()
{
return [
[''],
['fr'],
['francais'],
['FR'],
Expand Down
6 changes: 5 additions & 1 deletion src/Symfony/Component/Translation/Translator.php
Original file line number Diff line number Diff line change
Expand Up @@ -91,6 +91,10 @@ class Translator implements TranslatorInterface, TranslatorBagInterface, LocaleA
*/
public function __construct(string $locale, MessageFormatterInterface $formatter = null, string $cacheDir = null, bool $debug = false, array $cacheVary = [])
{
if ('' === $locale) {
trigger_deprecation('symfony/translator', '5.2', sprintf('Passing "" as the $locale argument to %s::%s() is deprecated, it will throw an InvalidArgumentException in version 6.0.', static::class, __METHOD__));
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure this case makes sense. It conflicts, from a logical pov, with the change in getLocale(). It's one or the other to me, isn't it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it depends.

If we say injecting an empty locale in the constructor is ok, because we make sure that the default locale will be returned in getLocale() anyway, then yes a deprecation is not needed. Only Tests need some adjustments then.

But if we say an empty locale is not valid, we could validate it in assertValidLocale() and also simplify getLocale() by removing the \?: Locale::getDefault(). But this would be a BC break if we do it right now, so I only introduced the deprecation for now and would do the adjustments of assertValidLocale() and getLocale() in version 6.

I personally would prefer the second approach, but I also might miss something :-)

Copy link
Contributor

Choose a reason for hiding this comment

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

we should patch assertValidLocale IMHO. deprecating an empty string there, throwing in 6.0

given the locale is not a nullable in this case, there's no need for fallback to \Locale::getDefault() as well

thus the deprecated case (an empty string) keeps working in 5.x, as currently that's a BC break.

we should proboably call $this->setLocale($locale) at construct (to ensure validation), meaning the deprecation will automatically happen as well.

Copy link
Member

Choose a reason for hiding this comment

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

I would personnaly take the other way, for consistency with TranslatorTrait, and because that's what provides the most power to users (they can decide to rely on \Locale::getDefault())

Copy link
Contributor
@ro0NL ro0NL Sep 18, 2020

Choose a reason for hiding this comment

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

it can also take a nullable again let's not :)

but yes, ?: getDefault() works, at most it hides "0" sneaking into the system. But it's consistent behavior with the trait, i agree.

IMHO the service differs from the trait, in a way doing new Translator(Locale::getDefault() makes sense, otherwise we have to document the empty string behavior as well i figured.

The trait needs a hardcoded fallback mechanism, due the lack of a constructor.

Copy link
Contributor
@ro0NL ro0NL Sep 18, 2020

Choose a reason for hiding this comment

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

we still need a deprecation here (and in setLocale) then

if (!$locale) {
    trigger_deprecation('will be Locale::getDefault() (currently "...") in 6.0');
    // $locale = Locale::getDefault()
}

and fallback as of 6.0

... so yes, the current behavior conflicts 😅

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 see the point of the deprecation. Let's move on.

}

$this->setLocale($locale);

if (null === $formatter) {
Expand Down Expand Up @@ -158,7 +162,7 @@ public function setLocale(string $locale)
*/
public function getLocale()
{
return $this->locale;
return $this->locale ?: \Locale::getDefault();
Copy link
Contributor
@ro0NL ro0NL Sep 23, 2020

Choose a reason for hiding this comment

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

see also #38279, we'll introduce the same issue now :)

}

/**
Expand Down
0