I think I must explain why I propose adding parameters. It is because
choosing a message by its ID is implemented differently in, for instance,
gettext and ICU. In ICU it's a single message including all the variants in
it so items number isn't required to get the message by its ID. For
gettext there are multiple messages so items number is actually required to
get the correct message.
Another thing that should be explicitly stated in the interface name is if
that's about final translation or just getting a raw string for further
processing. If that's getting raw messages I'd suggest renaming interface:
interface MessageSource
{
public function getMessage($id, $parameters = [], $context = null);
}
On Monday, April 1, 2019 at 3:15:12 AM UTC+3, Alexander Makarov wrote:
>
> Hello Oscar,
>
> If you need some expertise, I can be part of the working group.
>
> The document is a good start but there are some controversial and
> incorrect parts:
>
> 1. The message argument description should not specify that it is the text
> to translate. In fact, it is an ID to find the translation for. The ID
> could be message itself or just an ID. In Yii 2 we're using message itself
> that is, as well, used as a fallback in case translation isn't there. In
> Java it's common to use dot-separated IDs instead of real messages.
> 2. "The text to translate (in singular)" for plurals should not mention
> that it's in the singular. Different implementations may use different
> strings as message IDs.
> 3. It's stated that Yii doesn't have a way to handle plurals but in fact,
> it has one of the most advanced message translation layers that includes
> plurals support:
> https://www.yiiframework.com/doc/guide/2.0/en/tutorial-i18n#plural
> 4. The current interface is limiting usage in a bad way forcing you to
> concatenate the final message from many parts by not including an argument
> for passing parameters. It is extremely inconvenient to be limited to
> static messages without placeholders.
> 5. There could be multiple plurals in the message.
>
> Instead, I'd suggest a single method for the interface:
>
> public function translate($message, $parameters = [], $context = null);
>
>
> This way it covers regular messages:
>
> translate('Hello!')
>
> Plurals:
>
> translate('{n} cats', ['n' => 10])
>
> Parameter replacing:
>
> translate('Hello, {username}! Thank you for participating in
> {eventname}.', ['username' => 'Oscar', 'eventname' => 'PHP-FIG meeting'])
>
> etc.
>
> On Sunday, March 31, 2019 at 12:42:02 PM UTC+3, Oscar Otero wrote:
>>
>> I did suggest something like that some time ago, but it did not gain
>> enough interest.
>> There’s my initial proposal:
>> https://gist.github.com/oscarotero/33e3af8741045c2a1a5a89310571cbdb
>>
>> I’d happy if anyone want to work on this spec.
>>
>>
>> El 31 mar 2019, a las 3:57, Navarr Barnier <[email protected]> escribió:
>>
>> I feel like this would be a good idea, for managing the backend of
>> getting the translations.
>>
>> For formatting there's something native in PHP
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "PHP Framework Interoperability Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To post to this group, send email to [email protected].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/php-fig/1fdfacc8-d59b-4b7e-9040-ea936e4f3a4c%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/bd2f1de0-43d5-4293-9eb3-060b98f1aabf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
