Closed Itach1Uchixa closed 7 years ago
It already exists in the zendframework/zend-mvc-i18n package, via the TranslatorAwareTreeRouteStack
:
I knew existence of TranslatorAwareTreeRouteStack
but my idea is to get locale from route, not a route translation. Please read and check solution first. I think that you @weierophinney just read the title and made your decision.
Because I am offering:
/ru-ru/hello/world
not:
/привет/мир
or /privet/mir
TranslatorAwareTreeRouteStack
and my solution could complement each other like:
/ru-ru/privet/mir
/en-us/hello/world
P.S: Sorry for wrong and unclear class naming
You can do that with a root route that has the locale as variable in it. For example:
return [
'router' => [
'i18n' => [
'type' => Segment::class,
'options' => [
'route' => '/[:locale/]',
'constraints' => array(
// @see https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
'locale' => '[a-z]{2}'
),
'defaults' => [
'locale' => 'de',
],
'may_terminate' => false,
],
'child_routes' => [
'home' => [
'type' => Segment::class,
'options' => [
'route' => '',
'defaults' => [
'controller' => IndexController::class,
'action' => 'index',
],
],
],
],
],
],
];
Although your solution is more formulated and clear.
@MatthiasKuehneEllerhold In my old projects I did that, but problem is that the root route negatively affects modular architecture. For example, I can't just download and plug my modules that don't support i18n. In my case you will have to just configure your Application to support it and of course add translation files wherever you want and it will be enough. My solution will add it even for modules that doesn't support i18n. The main idea is to separate modules from that kind of attachment. Please try it yourself to understand what I mean.
@weierophinney please reconsider. It's a very useful solution! I understand that it needs refactoring I will refactor and optimize it.
If the zend-team doesnt want to include it into zend-i18n you could publish it as an extra module. We've gone the way I described above but I admit your solution sounds better for us too.
I have a few comments:
First, how sites provide a localization segment differs broadly. Some use ISO 639-1. Some use ISO 4646 (which is what PHP's Locale
uses internally). Some use RFC 3066 (which has a primary tag of between 1 and 8 characters, and an optional subtag with the same constraints, using ISO 639 as the primary source for the primary tag). My point is that any solution should try to be general, to allow the greatest number of users, as the selection of one or another is often based on business needs.
Second, the appropriate location for any such solution would be in zend-mvc-i18n, as that provides integration between localization/internationalization and the MVC (which includes the routing system).
Finally, opening an issue with an idea is fine, but we definitely prefer pull requests, which should contain unit tests and at the very least documentation containing examples; these two pieces demonstrate your ideas of how the functionality will be used, which allows us a better idea of how to evaluate the feature.
I look forward to evaluating the pull request with this feature on the zend-mvc-i18n repository. :smile:
It is just a concept, but it would be great if such feature would be added https://gist.github.com/Itach1Uchixa/6ec75b8f2af47a0b63e3f52fa0285a24