Closed (won't fix)
Project:
Internationalization
Version:
5.x-2.5
Component:
Code
Priority:
Critical
Category:
Feature request
Assigned:
Reporter:
Created:
11 Jan 2008 at 04:03 UTC
Updated:
7 Aug 2009 at 13:04 UTC
Jump to comment: Most recent file
Comments
Comment #1
pwolanin commentedComment #2
pwolanin commentedand in the patch too... (ua -> au)
Comment #3
pwolanin commentednote the patch was rolled form the modules directory, so you'll need to apply it as "patch -p1" if you're in the i18n directory.
Comment #4
neurer commentedWould love to see this for 5.x. Any idea, on when you'd be able to provide a patch? Would gladly assist in testing if that helps.
Comment #5
pwolanin commented@jant - the patch for 5.x will be similar (but the files have changed). I'll try to whip something up in the next day or so. Can you test (or at least look at) the 4.7 patch?
Comment #6
pwolanin commentedhere's the exact same patch for 5.x
Comment #7
jose reyero commentedThe idea looks good.
About the patch:
- There are some i18n api functions that could be used, saving some code, like i18n_default_language()
- The new settings look a bit confusing to me. The fact that we should note on the settings page is that this option is not compatible with 'browser language detection'.
I'm thinking of something like
Default path behaviour:
(How to handle paths without language prefix)
- Detect browser language and redirect
- Add default language prefix and redirect
- Assume default language (No language prefix for default language)
Does this make sense? Anyone can think of a better wording for these options?
Comment #8
mr.j commentedThanks. subscribing
Comment #9
mr.j commentedSorry I dont know why all the status flags changed on my previous message.
Comment #10
lazly commentedHi!
A try the last patch at 5.x, and i dont find any problem, it works fine!
Lazly
Comment #11
jacon commentedIt works! Yet I have a another problem with the language switcher - it contains the language prefix even for the default language.
How can we avoid that?
Comment #12
aexchecker commentedso need add option to omit the language prefix for front page when using the default language
Comment #13
druvision commentedConfirmed - it works for my pathauto-enabled one-language blog (http://www.levavie.com), where Hebrew (RTL) is the default language.
My blog is one-language. I needed I18n only for the RTL language detection used by the lightbox.
In my opinion, non-prefixing should be the default! Otherwise this breaks the upgrade path. You should put this default in the install script to preserve backwards compatibility for one-language sites. The facts that all URLs suddently change is not SE-friendly.
Amnon
-
Professional: Drupal Israel | Drupal Development & Consulting | Eco-Healing | Effective Hosting Strategies | בניית אתרים
Personal: Hitech Dolphin: Regain Simple Joy :)
Comment #14
druvision commentedWhen I said "This" I've meant the third patch, http://drupal.org/files/issues/i18n_prefix_default-687146-5x-6.patch
Comment #15
druvision commentedTested more deeply.
This patch needs enhancement in case multiple languages are enabled, and the default language is not English.
Current behavior is a bug: Language for logged-in user's is forced to be English regardless of their preferences or the path. My only remedy was to disable English.
Suggested behavior: In this case, it should still be possible to hide the prefixes for the default (non-English) language.
Comment #16
druvision commentedAdded info: My only remedy was to disable English and to revent back to the situation where only one language is enabled. Only then, it was backwards compatible.
Comment #17
aexchecker commentedI read post #13 - 16 and updated my path
Comment #18
sdecabooter commentedAexChecker, the last attached patch does not want to apply against the i18n 5.x-2.2 release.
Can you check?
Comment #19
aexchecker commentedBy logic
1. Simply change
i18n_frontpage2.
i18n_get_browser_lang3.
And Snippet for
_phptemplate_variables()as appendixComment #20
lejon commentedIs this how to fix the problem with image paths?
See: http://drupal.org/node/208474
http://drupal.org/node/222155
If it is, can you explain how to apply the patch? Sorry, I'm a bit of a newb...
Comment #21
sdecabooter commentedComment #22
aexchecker commentedI rewiev and fix my path. Pleas check it.
main changes:
Comment #23
aexchecker commentedfix problem for frontpage
Comment #24
jose reyero commentedHey, great that you got this fixed, but better don't change the issue status till we get the code committed :-)
(This is looking good, just I'm working on the Drupal 6 branch this days so I haven't yet tried this one, will be back soon)
Comment #25
hunvreus commentedGreat patch. I guess it'll be in the next version of i18n. There is a small problem though; try to set a Custom Language as a default language. Once you have switched to a non-default language, the Translations block urls are gonna be prefixed with the code of this language; if you browsed the french version www.site.com/fr/mypage, then Translations will display www.site.com/fr/en/mypage for the English version. Give it a try...
Comment #26
akahn commentedTracking.
Comment #27
lejon commentedIs this how to fix the problem with image paths?
See: http://drupal.org/node/208474
http://drupal.org/node/222155
If it is, can you explain how to apply the patch? Sorry, I'm a bit of a newb... Do you just replace the current i18n.module in the modules folder with your version above?
Thanks.
Comment #28
aexchecker commented2 post #25
Comment #29
aexchecker commented2 #27
I think, for
i18n_pathfunction need add additional chek_function for path for add lang prefixI write
_i18n_add_lang_prefix_for_path(), when I have more time.Comment #30
momper commentedhello
i searched so long for this solution - the absolutly right way - thanks a lot ... + please don't stop with this stuff - it's a must for a multilanguage system ...
i have to work with this on a production server - i hope i have luck :)
thanks thanks momper
Comment #31
momper commentedhello,
will this move some day into the i18n-dev?
i would be so happy ...
greetings momper
Comment #32
scedwar commented+1 - would love to see this functionality in the release.
Comment #33
momper commentedhello,
is it still usable in the 5.x-2.3 version - or is it in dev?
greetings momper
Comment #34
momper commentedhello,
can we collect some money for a bounty, to put it into dev for 5? does anybody want's to join?
@AexChecker - would you do it? or somebody else? i'm not a programmer ...
thanks and greetings momper
Comment #35
momper commentedhello,
is anybody interested in this stuff?
greetings momper
Comment #36
momper commentedhello,
anything new?
greetings momper
Comment #37
momper commentedall the people are into the 6.x release? i can't believe that i'm nearly the only one ...
greetings momper
Comment #38
willeaton commentedHi Guys, anyone else have the issue of the parent item drop down list not containing all of the menu items? Basically, it appears that my menu list it too long for the drop down of "parent item" and so if the node already exists and has a link set up, when I go to edit it and the parent item is at the bottom of the list (in fact so low, off the list) it messes my menus up and places the link in "navigation" instead of the menu its supposed to be in?
Thanks,
Will
Comment #39
scedwar commentedI think you're off topic with that! I'm only interested in getting rid of /en (or whatever the default language is) from the url.
Comment #40
willeaton commentedMaybe, I'm just seeing if anyone else had the same issue as a result of the above patch, if so then it is relevant, if not then it only helps me narrow down what is causing it and means everyone else has to scroll just that little bit more to hit the bottom of the page.
Comment #41
lazly commentedThe new version, 5.x-2.4 is not work with these patchs... Pls help!
Comment #42
momper commentedhello
i see big plans with internationalization and the localization client - but the standard request to not prefix a language is not possible ... all your clients agree with this? you tell them - sorry it's not possible? i don't understand it ...
greetings momper
p.s. i'm not a programmer - so i can't do it for myself - it would be wonderful ...
Comment #43
tille commentedhi,
I know this discussion is about Internationalization - and not Localizer - but since the requested feature seems to work without any problems with Localizer I thought it might be interesting anyways…?
http://drupal.org/project/localizer
…at least I just checked the following:
1) default language = English
english version --> domain.net/node1
german version --> domain.net/de/node1
2) default language = German
german version --> domain.net/node1
english version --> domain.net/en/node1
The related administration panel can be found here:
admin/settings/localizer
-> Language prefix
-> [x] Do not add prefix on the site default language
…for me it seems to work perfectly well - and I just hope that it will stay this way and that there's no other problems lurking from somewhere around the corner…:]
greetz, till.
Comment #44
OnkelTem commentedCleaning up patch provided and updating it to get it applied over 5.x-2.5.
Comment #45
luco commenteduhm. the patch failed. here's a .rej file.
Comment #46
jose reyero commentedSorry but we won't be adding new features to 5.x.
Please move on to 6.x