#117824: hiccup with login is about to introduce the Symfony HTTP request handling class that includes support for language detection in the request. We have custom code for that in our language negotiation that we can then get rid of. Look for getPreferredLanguage() and getLanguages() in the Request class.

Marking postponed until this Symfony HTTP library lands.

Parent issue

#1269834: META: Clean up language negotiation code

Comments

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented
Status: Active » Postponed

Actually marking postponed.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented
Issue tags: +symfony

Tag.

attiks’s picture

attiks commented

sub

podarok’s picture

podarok
🇺🇦 he/him/his
Primary language Ukrainian
Location Ukraine
commented

subscribe

lsmith77’s picture

lsmith77 commented

FYI: you guys might want to have a look at this PR and throw in your POV
https://github.com/symfony/symfony/pull/2227

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented
Title: Replace custom HTTP request language detection with Symfony code » Use Symfony / context code to retrieve HTTP language preferences

Once #1279942: Create Http context handler lands, we'll have a getValue('http:languages') to get the language list, our selection logic is still needed since there is no comparable solution in Symfony. Retitling for that. #1260918: Convert language globals to contexts is also related.

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
commented

@Gabor:

Once #1279942: Create Http context handler lands, we'll have a getValue('http:languages') to get the language list, our selection logic is still needed since there is no comparable solution in Symfony.

Do you mean we will have to retain the logic actually implemented in http://api.drupal.org/api/drupal/includes--locale.inc/function/locale_la... but get the list of accepted languages from the HTTP context handler?

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

Yes, since Symfony does not seem to have comparable logic. Unless we submit our logic to symfony that is and get it committed upstream. I'm assuming we work off of what we have so far, in which case, we should just use the information from the http context.

lsmith77’s picture

lsmith77 commented

@Gabor: I see 3 solutions:

1) if you can make the case that the Drupal correct and the current Symfony2 approach violates the HTTP spec, we will certainly need to have a look at how to fix that in Symfony2
2) if not you can check if it would be possible to migrate to the Symfony2 approach (from my understanding both approaches are "valid")
3) you could simple extend the Request from Symfony2 and override that specific method with your parsing rules

In any case I would move the logic to the Request, either by getting it changed upstream, by adopting the current upstream approach or by extending upstream.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

@lsmith77: well, we are getting that data from the HTTP context in #1279942: Create Http context handler, so the responsibility of providing that data is there. I think we discussed and made clear earlier that Drupal is *much* closer to the W3C / HTML5 standards than Symfony. As a web based system, we consider the W3C / HTML5 language codes to adhere to and using UNIX language codes seem like backwards to the web environment where we are. I'm not seeing that where would be a good case to go against W3C / HTML5 recommendations.

lsmith77’s picture

lsmith77 commented

@Gabor: could you open a ticket on the symfony repository and state your case there. then we can look with the other symfony developers how we can best improve things.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented

@lsmith77: Submitted https://github.com/symfony/symfony/issues/2468.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented
Issue tags: +language-base

Tagging for base language system.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented
Issue tags: +negotiation

Tagging for language negotiation too.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented
Issue summary: View changes

Add parent issue link

mgifford’s picture

mgifford
he/him
Primary language English
commented
Issue summary: View changes

This shouldn't be postponed any longer as far as I understand, since #1279942: Create Http context handler is in.

Crell’s picture

Crell commented
Version: 8.0.x-dev » 8.2.x-dev
Status: Postponed » Active

Refiling. May be won't fix at this point, since this issue goes all the way back to the ill-fated "context API". I defer to Gabor on what to do with it.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

smustgrave commented
Status: Active » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

smustgrave’s picture

smustgrave commented

wanted to bump this one more time :)

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.