Closed (duplicate)
Project:
Drupal.org security advisory coverage applications
Component:
module
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
9 Sep 2011 at 08:46 UTC
Updated:
10 Sep 2018 at 09:58 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
tvb commentedThis kind of functionality is very welcome. There seems to be no easy way in Drupal (6) to achieve this.
Looking at the attached screenshot (http://drupal.org/files/issues/ScreenShot136.jpg), some questions pop up:
1) To which page are the users redirected after selecting a language on the selection page? Ideally, they would be redirected to the initial URL but with the language prefix inserted.
2) The options under 'Use cookie to remember your language': can you elaborate what exactly the differences are between the three options? (e.g. the selection page is not bypassed when you select 'Oui', or is it? If not, what is the difference with selecting 'Non'?)
3) Does the selection page have a 'Do not ask again next time' checkbox?
Rgds,
tvb
Comment #2
polHello tvb,
I've updated the module during the week end and the options changed a bit.
I've also added more description to each of them, see the screenshots.
The first screenshot is the default template, which is ugly, but the user can override through the Drupal templating system. (sorry i'm not a themer!).
The second screenshot is the new options, it makes more sense.
The reply for your questions now:
1) Users are redirected to the same page they come from but with the correct language prefix.
2) If user select the first option(Redirect to a language selection page...) of the :
- No but redirect if language is found from cookie: means that the user will not be redirected to the language selection page, but to the page with the language prefix set.
- No: means that the user will never go to the language selection page (disabled)
- Yes: means that the user will always go to the language selection page (if no prefix from url), even if the cookie is set.
3) It's not needed in that case.
I hope it's ok ;-)
Bye.
Comment #3
batigolixIn some countries that have several official languages, the only political correct way of serving the visitor the website in his preferred language is by letting that visitor choose the language explicitly (instead of letting Drupal decide using url, user-agent, ip address, etc).
So I think Pol's module is quite useful for this
Comment #4
polHey, Hi Boris :)
Have you tested the module ?
If something goes wrong, just let me know ;-)
We are using it on 3 websites and no problems so far since the last update ;-)
See you !
Comment #5
polI pushed a new update with a new default page, thanks to Marc Hanot, a colleague for the HTML template.
Screenshot attached for the new page.
Comment #6
sreynen commentedHi Pol,
I reviewed the code and noticed some issues:
If this is a variable users might edit, it should be stored as a system variable. Users in general should not be editing module files, as that complicates updates. I'm not sure why this would need to vary between sites.
If you're going to keep it as a constant and remove the suggestion to change it, constant names should prefixed with module names to avoid conflicts. For example, if a module named "language_cookie" defined the same constant, the two modules couldn't work together. The same name conflict can happen in the cookie name as well. To avoid these problems, it should be something like this instead:
define(' I18N_SELECTION_LANGUAGE_COOKIE_KEY', 'i18n_selection_language_prefix');You'll also need to change that everywhere the constant is used.Comment #7
polHi sreynen,
I made the changes, thanks for taking time to review it !
If you have any new idea to implement, just let me know.
Comment #8
sreynen commentedOkay, this looks good to me.
Comment #9
gregglesSorry to do this, I'm setting it back to needs work. But the change I think should happen is small - the rest are suggestions.
Required changes
The administration menu callback should probably use "administer site configuration" - which implies the user can change something - rather than "access administration pages" which is about viewing but not changing configurations.
Suggested changes
Please take a moment to make your project page follow tips for a great project page.
This code seems hard to follow/maintain:
I suggest adding some comments explaining what the special numbers mean. Since they are used in various places around the code you could add the comment to the top of the .module since that is a likely spot to be found.
I noticed some very small code style issues. Please run the coder module on "minor" setting to help catch these. The coding standards have even more information in this area.
Comment #10
polHi greggles,
I made the changes.
I've also passed through coder and it returned no problem.
Thanks.
Comment #11
sreynen commentedComment #12
svendecabooterThere seems to be something wrong with the loading of the theme / preprocess functions.
On a clean D6 site i get a WSOD when choosing "Template only".
When choosing "Template in theme", the links are not shown - like this: http://grab.by/b4Iw
I ran this through a debugger, and it doesn't arrive in the preprocess functions. If I find time later I might try to find the cause of the problem, but thought I'd let you know already.
In i18n_selection_page.admin.inc you are passing variables into the t() function, whereas this should be a literal string.
See http://api.drupal.org/api/drupal/includes--common.inc/function/t/6
In i18n_selection_page.admin.inc line 41: you should use notation with brackets according to Drupal coding standards.
In i18n_selection_page.admin.inc line 65: you should probably use a placeholder for the variable in t() (not sure if this is also true for constants, but better safe than sorry)
This is a useful module. Keep up the good work ;)
Comment #13
polHi Sven,
This is something I don't understand yet, I need to figure this out, but until now, I did not found a solution.
Each time you make a change on that setting, you have to run a clear cache twice and it will work.
The others suggestions are done as well.
Thanks for your comment!
Comment #14
polHi all,
The last commit fix the theming problem and the WSOD.
Comment #15
funature commentedhello, where can i download the module?
Comment #16
greggles@euroba It's not available for download yet. It needs to be reviewed and then approved and then Pol can turn it into a full project.
This issue should have been in "needs review" status where it could get reviewed.
@Pol, please be sure to set it back to needs review when you're ready for more reviewing.
Comment #17
funature commentedi think it will be suitable for my purpose, see http://drupal.org/node/1344084
i hope i can use this module as soon as possible.
best regards
Comment #18
polPlease, review the module, it's stable enough.
Comment #19
doitDave commentedAutomated review (Please keep in mind that this is primarily a high level check that does not replace but, after all, eases the review process. There is no guarantee that no other issues could show up in a more in-depth manual follow-up review.)
Review of the 7.x-1.x branch:
This automated report was generated with PAReview.sh, your friendly project application review script. Go and review some other project applications, so we can get back to yours sooner.
Manual addition: Find the 6.x-1.x results attached.
HTH, dave
Comment #20
doitDave commentedComment #21
polHello,
The module is working for 6.x-1.x. The 7.x branch is not yet done and I'm still working on it.
I've updated 6.x-1.x, I hope it's better.
Comment #22
doitDave commentedD7 related: I did not get that at first sight, really sorry!
Will check the changes in 6.x asap then. Thank you for clarifying!
Comment #23
klausiReview of the 6.x-1.x branch:
This automated report was generated with PAReview.sh, your friendly project application review script. Go and review some other project applications, so we can get back to yours sooner.
manual review:
Comment #24
misc commentedhttp://drupal.org/node/1381494#comment-5513060
Comment #25
tvb commentedHello Pol,
I have tried the module on an internal development site with two languages.
Setup:
- Bilingual D6 site in dutch (nl) & french (fr) (nl is default language; english is disabled).
- There are two panel nodes in 1 translation set used as homepages (node/4463 for nl; node/4464 for fr). Both panels have fpanel1 as URL alias.
- Both panel nodes are overwritten by panels to display panes based on the language of the node being viewed (via a visibility rule).
- site_frontpage is set to fpanel1 (set in dutch interface; site_frontpage is not multilingual enabled because it may conflict with domain access module).
I don't know whether this is the recommended setup for a bilingual site, but this is how it is configured currently. It works fine using http://example/nl or http://example/fr : all content panes are displayed correctly.
But this setup does not provide for a neutral language selection page in case there is no language prefix found in the URL or in a cookie. This is where the i18n selection page module fits in.
These are my comments:
1) When the browser requests http://example for the first time (no cookie available), the redirect message displays the alternative links http://example/nl/fpanel1 for dutch and http://example/fr/node/4463 for french. But node id 4463 is the dutch version in the translation set, not the french version (4464). The result is a page with mixed french and dutch content.
Is it possible to have the french link use the alias also?
2) When a cookie has been set to use the french language and upon requesting http://example, there is redirection to http://example/fr/node/4463. This is however the dutch version in the translation set instead of the french version. (see point 1 also)
3) When the redirect message is set to by displayed in the template ('Template in theme'), the template also displays page elements in the default language (menu, sitename...) while the user has yet to select a language. I suppose this is because the URL of the page has a language prefix inserted (http://example/nl/language_selection?destination=node%2F4463).
4) When no cookie has been set and upon requesting a view without a language prefix (eg. http://example/view instead of http://example/nl/view or http://example/fr/view), there is an immediate redirection to the version in the default language.
This is also the case for a regular node (http://example/node/44 redirects to http://example/nl/node/44).
My expectation is that the redirection message is displayed in this case, but it isn't.
5) The module does not seem to work without clean URL's. Maybe it should be listed as a requirement somewhere?
Workarounds:
I found this out earlier this week. Installing the Global redirect module with 'Language path checking' enabled, offers a workaround for 1) and 2). It alters the node ID so that it corresponds to the language prefix.
That's it for now. I hope this is the kind of feedback you are looking for!
Rgds,
tvb
(No change of status because of http://drupal.org/node/1381494#comment-5513060)
Comment #26
polHello TVB,
Thanks for the report, I'll start working on this during the next following weeks.
Comment #27
xeontheone commentedThis URL is not functioning: http://git.drupal.org/sandbox/Pol/1191004.git
I really need the cookie functionality for my website. It's incredible that is not builtin into Drupal.
Where I can download your module?
Many thanks
Comment #28
polCheck: http://drupal.org/project/language_selection_page
Comment #29
avpaderno