This is kind of what I am thinking.
$error = "What the hell are you doing? Read the fine manual. Everyone knows
that you can not overwrite /etc/shadow from a web application.";
$foobar = new classThatImplements('\Psr\Localization\Translation');
$error = $foobar->translateString($error, $bcp47);
It would potentially allow applications to load their own translations into
such a class w/o needing to implement the backend themselves and then
retrieve them as needed, possibly even a class that is good at compensating
for translations the web application does not have translations for,
written by programmers who understand localization and create
implementations of the interface.
Many programmers do not really understand internationalization but could
write their web (or other) PHP applications to a standardized interface,
like how WordPress plugin developers can just use __('string') and do not
have to worry about it. And it would allow system administrators to choose
the implementation they want, possibly even commercial implementations that
will attempt to fetch translated messages from translation software when
translations do not exist.
On Friday, March 29, 2019 at 1:45:10 PM UTC-7, [email protected] wrote:
>
> Hi,
>
> Are there any plans to publish a localization interface - for things like
> BCP 47 tags for identifying languages, timezone identifiers, standardized
> date and time formats based on language, etc.?
>
--
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/6a2721fe-2c43-461b-8668-928ab806ac73%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
