Skip to content

[Routing] Add i18n feature #17262

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
imulot opened this issue Jan 5, 2016 · 6 comments
Closed

[Routing] Add i18n feature #17262

imulot opened this issue Jan 5, 2016 · 6 comments

Comments

@imulot
Copy link

imulot commented Jan 5, 2016

Hi,

Is it possible to add i18n routing feature directly in symfony stack framework ?

i18n routing example :
3 i18n routes for the same controller action :

  • /fr/contact/
  • /en/contact/
  • /de/kontakt/

As Symfony have Router and Translater component, It would be logic that these 2 components works together to provide i18n routing capability.
A few extra bundles provide this feature (like JMSI18nRoutingBundle), but in my opinion this need is very common and could be candidate to the symfony core.

What do you think about that ?

Regards,
David.

@jakzal
Copy link
Contributor

jakzal commented Jan 5, 2016

In my experience this is not really as common as it might look. Anyway, if there's already a good bundle, why duplicating efforts in the core?

@imulot
Copy link
Author

imulot commented Jan 5, 2016

I am currently creating a website which need i18n capabilities.
To improve webranking for my customers I would have liked this feature in symfony standard edition.
Router and Translation are included into core package and It is not senseless to implement i18n routing without use of an extra packages with all related drawbacks (deprecated call, less support, ...).

Even if today I choose JMSI18nRoutingBundle, if tomorrow i18n capabilities will be include in symfony core, I will glad to switch on an full-supported solution.
According to my personal findings on the web, lot of people need this feature and are not totally pleased to use extra bundle.

@jakzal
Copy link
Contributor

jakzal commented Jan 5, 2016

My point is, if there's a third party bundle that does the job well, there's no need to duplicate efforts in the core as it will only add to the already busy schedule of the core team. Symfony's flexibility that lets you to extend it easily is one of its main strengths.

Anyway, how would you envision this feature? So far you only described it in basic terms.

@ghost
Copy link

ghost commented Jan 15, 2016

@jakzal Sometimes it could be useful to add it to Symfony like it happened with the Ldap component. For sure Ldap support could be added by a bundle but it was added as official Symfony component. We also have a full ACL support and not everybody really need it. That because not always we should decline such feature requests.

I also agree to add full i18n support for routes in Symfony directly. It could be done as extra Symfony component if you think it should not be in the Symfony Standard Edition by default.

@jakzal
Copy link
Contributor

jakzal commented Jan 15, 2016

@JHGitty that's precisely why I'm reluctant whenever there's a proposal to add a new component. Ldap doesn't seem to be finished nor stable (see #16735), and ACL is in a process of removing from the core (see #15013).

Anyway, I'll repeat myself:

how would you envision this feature? So far you only described it in basic terms.

@javiereguiluz
Copy link
Member

I'm closing this issue for the reasons given by @jakzal:

  • This feature is less common than it looks.
  • There is already a bundle which solves this (JMSI18nRoutingBundle) and it works great.
  • We (usually) only add to the Symfony core the features used by the overwhelming majority of developers. For example we don't even include the features provided by FOSUserBundle, which are used by lots and lots of developers.

In any case, thanks for proposing this improvement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants