Default path prefix for English (and DBTNG it)

This might be a problem in the node translation system. A possible default for the default language is to have no path prefix. Some sites prefer to have their default language pages without a special prefix and their translated pages with prefixes. We got this on our TODO list and implemented specifically in the negotiation code. If other components cannot work with this, it should be a bug in other components probably (or possibly in the negotiation code). I don't think this is solved by enforcing a path prefix for English to solve problems with other components not working without path prefixes, because the system should work without path prefixes.

Or to put it cleanly, this is either a bug with the already included Drupal 6.x-dev language code or the translation module. Maybe you can provide more information to track where is the bug?

I just happened across a similar bug as well and have a patch for it, even.

I'm not saying that we should force this path prefix on people, but if they choose to use path prefixes on the settings/language/configure screen then it is good to have this setting already done for the default English installation. Someone can always remove this if they prefer not to have it, but I feel like using a path prefix is the default for most languages so it should be the default for the default language as well.

If you'd like to know some specific steps to reproduce the problem that I encountered I can post them as well.

Using today's HEAD I can no longer repeat the 404 error that I found earlier (nor the path alias error I found that this seemed to solve). So, I leave it to Gabor to decide whether providing a default path prefix for English makes sense or not. I'm not really sure.

http://drupal.org/node/199624 was an issue popping up because English had no default prefix, and the site admin did not think through how the language negotiation chosen works (path prefix with fallback), when there is no path prefix, so English was not accessible when the browser or user language was set to non-English. That might be an interesting related issue.

My vote goes for preference to enable prefixed in URL for all languages. I have a multilangual site and it's important for me to have prefix in URL so that it always remains constant even if CMS is changed.

I'm not sure this qualifies as bug, more like a feature request.

I just looked through locale.inc and it appears to me that in locale_add_language when a predefined language is added it _always_ gets a path prefix. So, if we don't add this patch then English will be the only language that does not have a prefix defined.

Since this fixes a 404 bug and makes English consistent with the rest of the languages, I feel like it should be considered and/or committed.

EDIT: not a 404, but a confusing one - mea culpa

Hm, the more I think about this, the more I think we should basically implement a redirect, when "Path with language fallback" option is used, and the language is identified with the fallback (on user setting or browser preference). So these kinds of language selections are properly visible, we get right bookmarkable and better SEO friendly URLs. The only possible problem is if we find a language to redirect to without a path prefix. Then we need to skip that language and fall back to the site default without redirection. Unfortunately these locale settings are a complex maze with all kinds of interdependencies.

I think we should leave that problem to a contrib - Drupal has long had redirect/duplicate content problems and doing a redirect in core at this stage would be a feature (right?).

I created an issue for it in the global redirect module's queue because that is the kind of thing that Global Redirect currently does.

Separately from that problem though, I think we should provide this prefix for English since we do it for every other language. right?

Not setting the default prefix is because this way English sites have their existing URLs kept intact when they switch to some path prefix based negotiation. This might or might not be a strong enough reason. It would be great to hear from others as well.

What about setting a message when either "path prefix" option is selected and one of the enabled languages doesn't have a path prefix? That would alert them to the problem and could provide a link to the edit pages where they could edit the prefixes?

I fear that very few people are building sites with content translation because it is in Beta and therefore we aren't going to get other input/reviews. I guess that's what Drupal6.1 is for.

There could be another option for user to select - "Always set default language prefix". In this case, backward compatibility is maintained for those who don't want the prefix added. And added extra feature for those who start from the beginning and want default language prefix enabled (like me).

subscribe

@Ognyan Kulev, can you provide your feelings on how this should be handled? We are currently debating about how to handle this so it would be helpful if you provided your advice on the proper way to handle this or whether or not the patch fixes the problem (note, the patch works during installation time, so you would need to reinstall a site to see it actually work).

Also, reassigning to 7.x.

I'm not sure exactly what this issue is for. Personally, I'm building a site in Bulgarian that have English translations, and I want both languages to have path prefixes. I guess some marketing departments may want to have "en" path prefix so that other languages/cultures don't feel inferior. And it looks more structured ;-)

BTW I was surprised to see that 6.1 doesn't handle path prefix things as expected and I filed #237140: Default language ignores Path prefix.

I expressed preference for using language path prefix for default language but there are cases when no language path prefix for default language is saner. For example when TLD is different than generic ".com", etc.: "example.bg/node" and "example.bg/en/node", but "example.com/bg/node" and "example.com/en/node".

+1 for adding /en. Lets put some backwards compatibility hack in place so new sites can have uniform URLs. I've been building out a new multilingual D6 site and it's a huge annoyance, the designers keep asking me if I can get en in the front of the URLs. I'm about ready to just stick a frew mod_rewrite rules and an outbound link rewriting in there to get it done.

On IRC, Gabor indicated that what I'm running into is a bug: #244162: Links not rewritten to include prefixes with 'Path prefix only' language negotiation

I'm trying to build a multi-language site in Drupal 6.1 and stumbled on this problem. When the site's default language is not English, and language negotiation uses the path prefix, then English pages can't be reached. When the user visits a node without a path prefix, it displays the node in the default non-English language and doesn't add the 'en' prefix to the links leading to English pages.

A patch proposed above that sets the prefix 'en' for English in the table 'languages' fixes this problem. But I think English should have the 'en' prefix ONLY on multi-language sites.

i'm embarrassed admit that i duplicated the issue Ognyan Kulev linked to in comment #16. So much for reading the thread before posting.

Since that behavior was a bug, I'm coming to the conclusion that the current decision not to have a prefix for English is correct. If the admin wants to prefix the default language then they can. And by leaving it off we make it clear that one isn't needed for the default language.

jurta, what do you mean by:

A patch proposed above that sets the prefix 'en' for English in the table 'languages' fixes this problem. But I think English should have the 'en' prefix ONLY on multi-language sites.

The only time the prefixes are going to come into play is when you enable the locale module and the only reason you'd want that is if you've got a multi-lingual site. So I don't think that concern really has any bearing on this patch.

Updated: After rereading that I realized that you'd install the locale module to enable local translations on a single language site but in that case you'd set the "Language negotiation" setting to None and the prefixes wouldn't be used anyway.

drewish, I agree that it is safe to apply this patch that sets English prefix to 'en' by default. And it is very desirable to do this because the missing 'en' prefix breaks many things.

Because Drupal supports not having a path prefix for the default language, having it by default or not is just a question of preference / view-point. Judging from Drupal 6 feedback, it looks like it might be a better idea to play safe and include that default in Drupal 7.

I am trying to upgrade a site from drupal 5 to 6. The i18n module for drupal 5 uses path prefix for default language also. So I have a problem with this "feature" (not having a path prefix for the default language) in drupal 6. The urls are changed after the upgrade for pages in default language.
There should be an option, or if the prefix is set, then drupal should use it..

As I see there is no willingness to solve it for drupal 6. Could it be solved in i18n module for drupal 6?

edit: I should write this comment into #244162: Links not rewritten to include prefixes with 'Path prefix only' language negotiation. Sorry for the noise..

I´m sorry for being sucha a noobie, but, how can normal people use this patch?
I mean, should I copy paste that on phpmyadmin or should I include that file somewhere`?
thank you

I´m sorry for being sucha a noobie, but, how can normal people use this patch?
I mean, should I copy paste that on phpmyadmin or should I include that file somewhere`?
thank you

@groden: Please don't change the version. This bug is being discussed for 7.x (right now). There's an excellent handbook page on how to apply patches, so go read that and use the forums if you have trouble with the patching.

I just want to say a huge +1 to add a language prefix to English by default for 7.x, even if we can't get it for 6.x. I always forget going to admin/settings/language/edit/en to set the prefix - and using "prefix with fallback", I then occasionally end up with not being able to reach English at all! (See comment #20.) For most people - single language English sites, and sites not using prefixes - this would change nothing, but when you are using prefixes, not having "en/" can quickly become quite the curiosity. So, yes, this would cause less confusion. And if people really don't want English to have a prefix, they could just remove it.

To round this comment off: the patch from #4 still applies cleanly (to HEAD) and works as advertised (adds "en" as the default prefix for English). RTBC. (I'd like to see this for Drupal 6 as well. It wouldn't change anything for sites having already installed Locale, but it would lessen the confusion for new sites that do. But I can also see arguments as why this would not be a good idea (behaviour change), so...)

I'd like Gabor to make the final call on this. He knows the language system better than anyone else.

Still applies, back to review for Gabor.

This week it took me a while to figure out that English didn't have a default path prefix. Is this fact documented? I searched the readme's and drupal.org but couldn't find anything.

So either +1 to this patch, or better documentation.

subscribe

Needs re-rolling for db_insert()

Subscribing.
I also raise an other issue against Drupal-6.6.

Eh. No. It doesn't need re-rolling. Greg's patch from #4 still applies fine to latest HEAD.

It was code needs work to DBTNGify the query, which I think makes sense

Here's a (untested) version of the patch which does both the prefix and DBTNG styleeeeeee.

I'd just like the DBTNG'ing to be done in its own patch... but oh well. (Especially since the DBTNG'ing has to be done, but the prefix is somewhat disputed.)

Cleaning-up the "locale module" issue queue as per http://cyrve.com/criticals.

The DBTNG has already landed with #473366: DBTNG locale.module. The path prefix for English language is being addressed in #338055: Ensure non-default languages always have a path prefix.