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] Added intl message formatter.#27399

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 11 commits intosymfony:masterfromNyholm:intl-formatter
Sep 4, 2018

Conversation

@Nyholm
Copy link
Member

QA
Branch?master
Bug fix?no
New feature?yes
BC breaks?no
Deprecations?no
Tests pass?yes
Fixed ticketsreplaces#20007
LicenseMIT
Doc PR

This PR will replace#20007 and continue the work from the original author.

I've have tried to address all comments made in the original PR.

frankdejonge, danrot, hason, MatTheCat, Koc, artursvonda, sstok, and apetitpa reacted with thumbs up emojisstok and apetitpa reacted with heart emoji
*/
publicfunctionformat($message,$locale,array$parameters =array())
{
$formatter =new \MessageFormatter($locale,$message);
Copy link
Contributor

Choose a reason for hiding this comment

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

When the parsing of this message fails you get a very non-descriptive exception message (Constructor failed). Might be good for DX to rethrow a more descriptive one.

Koc reacted with thumbs up emoji
*/
privatefunctiongetFormatter(string$domain)
{
if (isset($this->formatters[$domain])) {
Copy link
Contributor

Choose a reason for hiding this comment

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

this could be reduced to:

return$this->formatters[$domain] ??$this->formatters['_default'];

Copy link
Contributor

Choose a reason for hiding this comment

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

And we can declare return type also


publicfunctiontestFormatWithNamedArguments()
{
if (PHP_VERSION_ID <50500 ||version_compare(INTL_ICU_VERSION,'4.8','<')) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Checking for php version is redundant

"php":"^7.1.3",

Nyholm reacted with thumbs up emoji
@nicolas-grekasnicolas-grekas added this to thenext milestoneMay 29, 2018
@Nyholm
Copy link
MemberAuthor

I've rebased this PR and updated according to feedback.


/**
* @param string $domain
* @param MessageFormatterInterface $formatter

Choose a reason for hiding this comment

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

to be removed :)

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Thank you. I added: void as return type.

/**
* @param string $domain
*
* @return MessageFormatterInterface

Choose a reason for hiding this comment

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

to be removed (and a real return type be used instead)

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Thank you

@Nyholm
Copy link
MemberAuthor

Anything I can do to help review this?

@artursvonda
Copy link
Contributor

Love the change and allowing to get rid of special case of transChoice (over time).

The original PR mentioned something about storing format with the messages and I actually tend to agree with it. The format IS information that's directly coupled with actual messages (basically, a meta information about contents of the file). This becomes even more important if translations are coming from external source and are not part of source files. There already have been talks about allowing different caching mechanisms and sources (like database) so coupling domain to format in config would not allow for changes in message format without deployment (and would make syncing changes hard anyway).
Catalogues already support metadata so we can add formatter as additional key there and maybe think about making formatter metadata part of actual message which would allow even more granular transition of messages from one format to another.
Architecture wise this would mean a bigger change long term with messages probably being objects (or structs) containing metadata but short term we can just use similar strategy as in this PR but configure domain => formatter relation automatically based on metadata in translation files.

jvasseur and sstok reacted with thumbs up emoji

@nicolas-grekas
Copy link
Member

Added to project "Contracts" after comment#28210 (comment)

*/
publicfunctionchoiceFormat($message,$number,$locale,array$parameters =array())
{
return$this->format($message,$locale,$parameters);
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this kind of implementation right? Argumentnumber is unused.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think we shouldn't implement theChoiceMessageFormatterInterface instead, it will disallow using thetransChoice method which is right since we should only use thetrans method for intl-formated message.

Nyholm reacted with thumbs up emoji
}catch (\Throwable$e) {
thrownew \InvalidArgumentException('Invalid message format.',$e);
}
if (null ===$formatter) {
Copy link
MemberAuthor

Choose a reason for hiding this comment

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

It will never be null here

@nicolas-grekas
Copy link
Member

I like it, but I would make the new formatter accessible only throughtrans() and not throughtransChoice() which should support only the Symfony syntax.
This would pave the way to deprecating transChoice at a later point in time, followingthis comment from@Koc.
I'd suggest to wait for#28210 to be merged before rebasing this PR and resolving this very comment.

@nicolas-grekas
Copy link
Member

Some description of the format here:
https://messageformat.github.io/messageformat/page-guide

sstok reacted with heart emoji

@NyholmNyholmforce-pushed theintl-formatter branch 2 times, most recently from7358b74 todaaceb0CompareSeptember 3, 2018 22:13
@Nyholm
Copy link
MemberAuthor

I've updated this PR.
I did some major changes. I removed support for multiple formatters. Instead, I added aFallbackFormatter.

With the fallback formatter we can support both "Symfony style plural" and intl messages at the same time. This will make sure we have a zero config solution for adding support for this new feature while all the old formats still works as expected.

Possible update: I could make theFallbackFormatter less generic by using the following constructor signature:FallbackFormatter::__construct(IntlMessageFormatter $first, MessageFormatter $second). The logic will be simpler if I do this change.

if (!\extension_loaded('intl')) {
$this->markTestSkipped(
'The Intl extension is not available.'
);
Copy link
Member

Choose a reason for hiding this comment

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

should be on one line


class IntlMessageFormatterTestextends \PHPUnit\Framework\TestCase
{
publicfunctionsetUp()
Copy link
Member

Choose a reason for hiding this comment

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

should be protected

);
}

privatefunctiongetMessageFormatter()
Copy link
Member

Choose a reason for hiding this comment

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

I think this can be inlined instead.

* Started using ICU parent locales as fallback locales.
* deprecated`TranslatorInterface` in favor of`Symfony\Contracts\Translation\TranslatorInterface`
* deprecated`MessageSelector`,`Interval` and`PluralizationRules`; use`IdentityTranslator` instead
* Added`IntlMessageFormatter` and`FallbackMessageFormatter`
Copy link
Member

Choose a reason for hiding this comment

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

missing space afterand.

* file that was distributed with this source code.
*/

declare(strict_types=1);
Copy link
Member

Choose a reason for hiding this comment

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

AFAIK, we are not using this anywhere else, this should be removed.

return$this->secondFormatter->choiceFormat($message,$number,$locale,$parameters);
}

thrownewLogicException(sprintf('The no formatter support plural translations.'));
Copy link
Member

Choose a reason for hiding this comment

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

The message is not so clear to me :) I suppose you meantNo formatters support plural translations.

try {
$formatter =new \MessageFormatter($locale,$message);
}catch (\Throwable$e) {
thrownewInvalidArgumentException(sprintf('Invalid message format. Reason: %s (error #%d)',intl_get_error_message(),intl_get_error_code()),0,$e);
Copy link
Member

Choose a reason for hiding this comment

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

As an exception should end with a dot, I suggest to useInvalid message format (%s, error #%d). Same below

@Nyholm
Copy link
MemberAuthor

Thank you for the review, Ive updated the PR

{
try {
$result =$this->firstFormatter->format($message,$locale,$parameters);
}catch (\Throwable$e) {

Choose a reason for hiding this comment

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

Can we be more specific here? We should be as much as possible IMHO (same below.)

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Do we want to be more specific?
I know the IntlMesaageFormatter only throws InvalidArgument, but isn’t it a good idea to catch everything to give the second formatter a change to run?

Copy link
Member

Choose a reason for hiding this comment

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

I agree with@nicolas-grekas

Copy link
Member

@fabpotfabpot left a comment

Choose a reason for hiding this comment

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

With one small comment. In a followup PR, we should deprecate the old way, deprecatetransChoice and probably try to write a script that converts our proprietary format to the intl one. WDYT?

useSymfony\Component\Translation\Formatter\FallbackFormatter;
useSymfony\Component\Translation\Formatter\MessageFormatterInterface;


Copy link
Member

Choose a reason for hiding this comment

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

should be removed

useSymfony\Component\Translation\Formatter\FallbackFormatter;
useSymfony\Component\Translation\Formatter\MessageFormatterInterface;


Copy link
Member

Choose a reason for hiding this comment

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

should be reverted

@nicolas-grekas
Copy link
Member

In a followup PR, we should deprecate the old way, deprecate transChoice and probably try to write a script that converts our proprietary format to the intl one

💯 for both!

Nyholm, MatTheCat, Koc, and sstok reacted with thumbs up emojisstok reacted with hooray emoji

@Nyholm
Copy link
MemberAuthor

Thank you. PR updated.

I agree to deprecate transChoice

@fabpot
Copy link
Member

Thank you@Nyholm.

@fabpotfabpot merged commit2a90931 intosymfony:masterSep 4, 2018
fabpot added a commit that referenced this pull requestSep 4, 2018
…, Nyholm)This PR was merged into the 4.2-dev branch.Discussion----------[Translation] Added intl message formatter.| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | yes| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets | replaces#20007| License       | MIT| Doc PR        |This PR will replace#20007 and continue the work from the original author.I've have tried to address all comments made in the original PR.Commits-------2a90931 csfb30c77 Be more specific with what exception we catchb1aa004 Only use the default translator if intl extension is loadedf88153f Updates according to feedback597a15d Use FallbackFormatter instead of support for multiple formatters2aa7181 Fixes according to feedbacka325a44 Allow config for different domain specific formattersb43fe21 Add support for multiple formattersc2b3dc0 [Translation] Added intl message formatter.19e8e69 use error940d440 Make it a warning
@NyholmNyholm deleted the intl-formatter branchSeptember 5, 2018 20:21
fabpot added a commit that referenced this pull requestOct 6, 2018
…from contracts (Nyholm, nicolas-grekas)This PR was merged into the 4.2-dev branch.Discussion----------[Translator] Deprecated transChoice and moved it away from contracts| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | no| BC breaks?    | no| Deprecations? | yes| Tests pass?   | yes| Fixed tickets | n/a| License       | MIT| Doc PR        | Issue:symfony/symfony-docs#10264This will address comment made here:#27399 (review)This PR moves the `transChoice()` method away from Contracts and back to the component. I also reverted changes in the `IdentityTranslator`. I will still use the deprecated `MessageSelector` but this is not fine since `transChoice()` is also deprecated.Commits-------dc5f3bf Make trans + %count% parameter resolve pluralsd870a85 [Translator] Deprecated transChoice and moved it away from contracts
@nicolas-grekasnicolas-grekas modified the milestones:next,4.2Nov 1, 2018
This was referencedNov 3, 2018
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@nicolas-grekasnicolas-grekasnicolas-grekas left review comments

@fabpotfabpotfabpot approved these changes

+3 more reviewers

@KocKocKoc left review comments

@frankdejongefrankdejongefrankdejonge left review comments

@jvasseurjvasseurjvasseur left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

4.2

Development

Successfully merging this pull request may close these issues.

9 participants

@Nyholm@artursvonda@nicolas-grekas@fabpot@Koc@frankdejonge@jvasseur@carsonbot@aitboudad

[8]ページ先頭

©2009-2025 Movatter.jp