languages in order of preference

... links inside nodes should use the same language as the node language, so users would not be redirected to a different language when browsing the site in their non-preferred language

Good point, but it's not so simple - the question is *why* is the user currently reading a node which is not in his/her preferred language? It could be through choice (in which case I agree, further links should point to the *same* language as the current node) ... or it could be because no translation of the current node exists in the user's preferred language (in which case links in the content should point to nodes in the preferred language, if available - the current behaviour.) I suppose MultiLink could try to work out which is the situation. I'll think about how to do that.

You probably know, the user's preferred language (single value) is a standard Drupal feature. I did think about extending that to allow multiple preferred languages in order. This could have many applications, not just for MultiLink, so needs to be independent of MultiLink, e.g. another module which extends the user's language preferences in the standard user account page. I'm a bit surprised that nobody else has done that yet.

I've changed this from "bug report" to "feature request". The current behaviour is not a bug (unless I am misunderstanding what you're saying.)

I've been thinking more about this. I cannot see a simple solution - the problem is how to know that a user chose to view content in a language other than their preferred language, as opposed to arriving there by some other route (e.g. a link from elsewhere.) So for whatever reason they've arrived at something like www.example.com/fr/english-content - If that content contains a link to another node and that node is available in both French and English, how do we know which version they would prefer to see? I don't think we can assume that simply because they are at www.example.com/fr/english-content then they want to see all further content in English. if www.example.com/fr/french-version-of-english-content also exists (why didn't they go there?) then maybe they have chosen to see English content (while keeping the site interface in French) by going to www.example.com/fr/english-content - but really, we don't know. So, currently MultiLink will show links to French versions, because that is considered to be their preferred language.

Ok, this could be a configurable option, but I think the current behaviour is the best. The user has the option of switching to www.example.com/en/english-content - then all links will be to English versions too. If made a configurable option, it would probably need to be a per-user option - that's quite a lot of extra complexity for something which I think is currently adequate, if not ideal.

So, I welcome further input, but my current feeling is to leave it how it is.

Ok, let's ignore case (1) ... moving on to (2) ...

Yes, it seems I misunderstood. So, effectively you want to ignore the user's language preference (stored in user account) and use the language of the current page instead? Would this be for all users? Ok, I suppose this could be a configuration option, it would be easy to do as a small patch too.

I'm interested to know that, other than this limitation, your use seems to be very similar to the scenario which I designed this module for. Could you give me the address of your site? Just professional curiosity!

Ok, quick way to get the functionality you want is to change line #235 in multilink.module from:

    $languages = array($user_language->language, $language->language, $default_language->language);

to:

    $languages = array($language->language, $default_language->language);

.. that will then ignore the user language preference and use the current language instead.

Thanks for the private message.

Hi:

I would like to say there is more going on with this issue. In some circunstances, the behaviour of Multilink will lead to incorrect urls, related to what Pasqualle describes as an invalid situation:

1. there should not be a valid use case for a page like www.example.com/fr/english-content in D6, so I do not know why we are talking about it.

I have set 'en' as preferred language. I'm developing a multlingual site, so I must browse all the available languages (this makes ML behaviour adequate, but not ideal).

I'm watching an 'es' page containing a link to another page [149:title]. ML correctly determines I should be looking only at english content (I'm okay with this), so builds a link to 'node/150' (node/150 is the english version of node/149). The problem arises when using Language Negotiation set to use any of the two path prefix option. ML is not explicitly saying which language the link must be (its only saying node/150). So the decision is left to language_url_rewrite() in includes/language.inc.

Here happens the contradiction, if no language is defined in the $options parameter, this function will set the prefix to the current page language (which is 'es'), while ML is asking for a prefix in the user preferred language (en). So I'll end with a link like '/es/node/150' which will not be a clean url (the link should be '/en/node/150'). As stated by Pasqualle, this is an invalid situation.

Of course, removing the user preferred language as the first option will make ML behave exactly the same way language_url_rewrite() does. The error is gone, but the problem remains in the underground.

HTH

I want to check that I am understanding correctly. I think you are saying:

* When en is the default language, ML will generate links like /node/150 (no language prefix).
* That path gets changed to /zz/node/150 (where zz is the language of the current page) due to language_url_rewrite
* Therefore, ML should always include a language prefix in the path which it generates (change to current behaviour.)

Please confirm, thanks.

Ok, I've been looking at this some more. It's more complex than it first appears...

Case #1

* My preferred language is English.
* The site default language is English
* I'm looking at en/node/123 which is in English, and contains a ML link to node/20, currently only available in Spanish.
* Multilink generates the link as en/node/20 - so if I click it I will see the Spanish content, but everything else stays in English, as I prefer.

Case #2

* My preferred language is English.
* The site default language is English
* I'm looking at es/node/123 (why!?) The content is in English, but site interface is in Spanish. It contains a ML link to node/20, currently only available in Spanish.
* Multilink generates the link as es/node/20 - so if I click it I will see the Spanish content, and everything else stays in Spanish. Not what I would prefer, but due to language_url_rewrite which uses the currentlanguage to generate the url.

Well, I think the current behaviour is not bad, but maybe in the second case the link should be the same as the first case, i.e. en/node/20, because en is my preferred language.

I think:

* In case #1, we should not switch the entire site to Spanish, only display the Spanish node (everything else in English.) That's current behaviour.
* In case #2, we should probably honour the user's preferred language, i.e. the link should be en/node/20, as in case #1, but maybe this should be configurable.
* In case #2, maybe it was invalid to be looking at es/node/123, since Spanish is *not* my preferred language, and anyway node/123 is in English. This could be handled with MultiLink Redirect (though is not current behaviour) by redirecting to en/node/123.

So, I will try to implement this, I'm not sure if it needs to be a configurable option.

Ok, now addressed in 2.2 release. It uses the user's language preference to generate the url.

Added some further documentation here: http://drupal.org/node/907514.

Actually, maybe this is *not* addressed in the new version! What the new version does is always try to respect the user's preferred language (which comes from browser settings in the case of anonymous users.) So, if user preference is de, then a link to English content at node/123 will be de/node/123 - i.e. node content in English and the rest of the site in German. What I think has been said above is that *some* users may want to switch the entire site to English, and so view en/node/123 - the rest of the page (block, menus, etc.) would then be in English too. Who would this be? I guess admins and translation staff mainly? In that case it could be best added as a permission/role based feature. Or what other users, even anonymous users need this feature? (in the case of anonymous users, how would we know?).

Well, in the meantime, the patch described in #6 will still work to disable user's preferred language.

Your input appreciated.

Well, I think in this case, it helps to draw a matrix to see what people want. www.example.com in my case helps the end user select their preferred language using the language drop down, so for this discussion, let's say that user is french, and www.example.com default presentation for the user interface is English.

Once selecting French from the language selector drop down menu, it will redirect to fr.example.com.

So far, using the interface option did not alias my english nodes, as I believe multilink is only set for none domain only aliasing, but it is not hurting my use case at the moment.

So upon selecting fr.example.com, the content selection portion of the multilingual system tab of Home › Administer › Site configuration > Languages determines how the content is displayed next, which can be independent of the content selection.

So after this is when multilink should set a reasonable default, based on preselected rules, and give the admin a choice on overriding the default behavior; however, I am using Active Translation (to keep user interface language options consistent), and Select Translation is also enabled, in case I want to showcase View based nodes, which could be helpful for showing fonts, other languages, etc., so multilink has to be aware of the weight of those modules.

So this table helps to visualize the steps a little bit, but multilink acts more as a content selection mode for the user, as opposed to switching the user interface, but is acting more broadly in switching user interface as well due to what it's linking.

Oh, can you fix for "domain only" please, or did I not configure the input right somehow, with my use of Domain Access as well? Or should I be using redirects, because I would really like my paths aliased when I have an original en content, and when the user is at fr.example.com/node/100, it doesn't look so great. What do you think?

Use case for separating user interface from content selection, could be for buyers, travel agents, etc., where the native tongue is preferred unless a foreign tongue is absolutely required. I think having a default link process, along with an override tag function(s), where the administrator can add code to make exceptions is the best solution. So, for example, if multilink gives links based on the user's interface language of, say fr, while looking at en content, the admin can also decide to override what the module does by wrapping links with an {en} or {fr} code that has a unique namespace (for the multilink to identify and process), within any content types.

Edit: After taking a look at the documentation again, if I don't specify and add multilink tags, the only other choice is to use the redirect submodule, correct?

Hi:

This is getting extremely complex to understand, to develop and also to document (IMHO). And I think it should not get to this complexity so far.

I skipped the 2.2 upgrade and I've been 3 days avoiding the upgrade to 2.4 because the lot of time required to understand the changes made by netgenius. I will try to explain my thinkings avoiding as much as possible to talk about node/xxx in language 'yy' because I think the problem is deeper. I will only refer to the path prefixed situations of language negotiation.

Quoting Pasqualle:

... links inside nodes should use the same language as the node language, so users would not be redirected to a different language when browsing the site in their non-preferred language

Quoting netgenius:

Good point, but it's not so simple - the question is *why* is the user currently reading a node which is not in his/her preferred language?

or

...the problem is how to know that a user chose to view content in a language other than their preferred language...

Short answer: You don't know and will never know why.

What is a preferred language? Something entirely up to the user and totally umpredictable from any logical point of view. For me the preferred language is not something objective and fixed, is subjective and easily changeable determined by the situation you are facing (and situations vary). ML is trying to achieve something that IMHO is impossible. To guess what the user wants to do, and in which language "should" be the link about to be clicked. So all the efforts by ML in that direction will be only "adequate" and a failure for sure under the precise circunstances.

The expected behaviour in every site navigation is that the user must define the language and continue the navigation in that language. For some unknown reason, the user wants to change the language? Ok, give her/him the option, click it and go on navigating in that way. Only one reason justifies to change the content language without the user explicitly wanting to: content unavailable in current language) otherwise is user's choice (more on this later).

Not even in the world of Drupal this is the standard behaviour. In no case the preferred language is taken as the first choice in the logic behind the language negotiation. And why is that? I think that is the answer to the following netgenius question:

You probably know, the user's preferred language (single value) is a standard Drupal feature. I did think about extending that to allow multiple preferred languages in order. This could have many applications, not just for MultiLink, so needs to be independent of MultiLink, e.g. another module which extends the user's language preferences in the standard user account page. I'm a bit surprised that nobody else has done that yet.

Even worst is when on a single Drupal page, are several links, some of then generated by ML and some generated by other modules. The result is a mixture of "smart-generated-links" by ML and "standard-generated-links" by Drupal. So, once more, my question is why not to attach to the Drupal's behaviour? ML depends on Drupal and not viceversa.

I'm pretty sure that the *Definitions* section on the MutliLink - documentation is far from complete. There are more LXXs about to be discovered, and consequently the *Behaviour* will have to be redefined again trying to embrace all the discovered LXXs. ML should be concise about what is able to do, following the paradigm of the good module: do one thing and do it well.

What should ML do?

• Simplify the management of in-content links to other content (nodes)
• In case of content unavailable in the current language, point the link to some other language (highlighting that the link is not in the current language) and from that point on let the user follow the navigation in the "some-other-language" in an unobstrusive way
• Avoid at all costs to mix interface in one language with content in another language (for me this is undesirable, but maybe someone I'm not sure about this one, just what I think)
• Avoid at all costs leading to invalid URLs like would be es/node/150 when node/150 is in french (I'm pretty sure this path can't be aliased, and this will have mid-term "consequences" with search engines indexing your site) - This is what #7 is talking about

I guess that's it... In a few words I think that #6 is the solution and not #9 (that will invariably lead to #12). Maybe someone re-reading the entire thread, the persistent problems, the solutions they had received, will be able to understand what I'm trying to say. I'm expecting to hear what others have to say (hoping that will happen).

Please don't misunderstand my words. This is not a rant and I'm not trying to criticize the maintainer's valuable work. I want to collaborate by all means and I'm just trying to set an starting point that will let ML be a less "fuzzy" module. Extremely useful as is and an indispensable tool in the multilingual world of Drupal-made sites.

Thanks a lot

MyXelf

I really disagree with you questioning netgenius' query into knowing "*why* is the user currently reading a node which is not in his/her preferred language". He doesn't need to know of all the reasons why, but only needs to know enough of the classification structure for these sort of problems to provide enough options and bounds with his module in providing the right type of links. So his question was on the mark.

I made an ommission last time. The i18n module provides the features that I was talking about in regards to "Configure" and "Multilingual system" selection under admin/settings/language.

ML can achieve something that is VERY possible. The most frequent use case of multilingual sites is in providing native language options for a user that speaks only one language; however, the defaults available by the i18n module has English (or other) as a fallback, and many speakers in Europe are multilingual, but have a native tongue which they prefer, thus having a preferred interface language to fall back on, while the content is in another language is ideal for self-translation or machine translation purposes, which already fits the bill in regards to the awareness that ML has.

The "standard-generated-links" by Drupal/i18n content become part of the page, after combining with the user interface language links provided by Drupal/i18n, thus there are two independent factors, and this is why multilink needs to negotiate its links based on both of those factors.

So, most modules don't necessarily translate every string into another language, depending on the modules enabled, and the default language is in English.

Anyway, Drupal workflow with i18n is most easily understood to be assumed as though it negotiates for the language of the user interface first, then the content language, then providing links to the nodes, and then providing any path aliasing of those nodes. Modules can and does step in at any part of this process, but it should be processed afterwards by providing an override, if it wants to integrate more easily with the ecosystem, like themes do.

The Multilink documentation does needs some work for a non-developer though.

So as to what ML should do:

"Simplify the management of in-content links to other content (nodes)" - I think the first two methods provided out of the three by ML (per documentation), works. It provides a method for putting in tags, by adding an input filter for content types, while the second option (which can be concurrently selected), provides a section within the content type form to redirect language content. If you have a lot of fundamentals, stuff gets complex. So my support request earlier was invalid, since I didn't really know how ML works. I thought most of it was automatic, but it provide semi-automatic features. It is not a global redirect/path redirect like replacement, which was what I was seeking for path aliasing on a system level - not node specific.

Currently, there are modules that converts the entire page via google translate, and not just the nodes. Select translation could work for developers in this case, but I haven't examined yet.

The user interface and content selection should be independent of each other, since i18n is generally part of the picture for multilingual sites, so I disagree with you here, once again.

Avoiding invalid URLs starts with providing links after identifying the user's preferred interface language, and the user's preferred content language (as set by i18n), regardless of whether or not the site master makes that choice for them. This is in most cases however always the same - which is one language, but keep in mind that a translated version doesn't always exist, thus content selection fallback is already provided.

I hope this helps the discussion in regards to the functionality that ML should provide.

Regards,

Paul

Netgenius, some additional documentation would be good to have. I think I read in one of your group posts, that path aliasing for languages is possibly in the works. Thanks.

Also, it would be good if you enfolded active translation into this project, as the maintainer of that project wants to step down.

Please open a new issue for the domain-based language selection issue. I is supposed to work, and I did test it some time ago, it may have stopped working for some reason in new versions, or maybe its dependent on site configuration and other modules. ML doesn't process the urls by adding or removing language prefix - it leaves that to the Drupal functions.

At the moment, ML does not need nor assume that the i18n ("Internationalization") module is installed. This was a deliberate decision, to keep things simple. But maybe it's time to add some support for i18n, and maybe other modules such as Active Translation.

Now I'm going on to read the rest of the new comments... this is getting interesting!

I had to do something else, and in the meantime netgenius showed up. Anyway I'm throwing this in... I'm pretty sure this is getting interesting :-D

------

I would prefer your answer to be a detailed comment of all the items I related in my post. Looks to me that you are talking about an ML module that is not the one we are using right now, and one that will not be available in the near future due to the complexity of the topic and lot of functionalities that must be developed.

I also would prefer to leave i18n out of the conversation. This module is known by having lot of things to be done and lot of another things that are not working as should be, despite the awesome work is capable to do in the multilingual aspect.

I'm sure that loading ML with lot of configurable aspects at the end will broad the audience and the usability of the module itself. But right now, in this very moment (and to the extend of this thread) I do have #6 as a solution to a problem and a #12 as the confirmation from netgenius that something is not as should be. I can see two options, including the configurable options (will not happen tomorrow) or try to address the basic functionality of the module, simplify it, and later when that part is covered, start trying to increase the number of functionalities.

AFAIK (maybe truly nothing) in language negotiation and in content selection (Drupal + i18n) the first choice is the current language, not the user preferred language. ML is doing it the other way around. And exactly this is what is causing the problems described in this thread. I'm trying to navigate a site in a different language, and every link generated with ML will pull me out to the preferred language. Based on what? Of course there are many more situations that would require this (i.e. the one related by the author of this issue). Note that I'm not speaking about "content being unavailable" in which case the current behaviour of ML is the one that should be in my opinion.

The multilingual stack is very complex and a lot of things overlap or solve some part of a bigger trouble. On a standard site using Content Translation + Locale + i18n + Pathauto + Token if you start to tweak all the configurations to suit your needs, you will end with an unmanageable site (taking into account the lot of documented constraints that already exists), and things will cease to function the way it should.

I see your matrix as a more complete vision of the LXXs items related by netgenius in the documentation. As a written proof of all that needs to be done in ML. Isn't it extremely complex? Think about explaining that to a regular user or to a newbie. Someone that should grab all those aspects to be in conditions to know and *be in control* of every aspects related to links generated by ML.

I don't think that hacking the module to solve a problem is acceptable, that's why I'll change the status of this thread.

Keep in touch, and thanks for your time

MyXelf

PS: Anyone knows where is netgenius? :-D

@vividgates re #14:

So, for example, if multilink gives links based on the user's interface language of, say fr, while looking at en content, the admin can also decide to override what the module does by wrapping links with an {en} or {fr} code that has a unique namespace (for the multilink to identify and process), within any content types.

It occurred to me to do something like that when I originally designed ML, i.e. be able to specify languages as part of the tag. But I didn't do it as it seemed at the time to be unnecessarily complex. So, now I could extend ML's tag format to allow behaviour to be altered on a case-by-case basis - that's powerful because it means that behaviour can be defined by the source content rather than the target content. As to the format of the tags, I like tags to be simple to type and remember, and as logical as possible. Currently we have [1234: Title goes here] (you can change it in "advanced" settings). How about something like the following? ...

[1234: Title goes here | flag, flag, flag ]

Where flag will be simple words like current, user representing languages, and specific codes for specific languages. The order of the flags tells ML what the language preference order should be in this case.

Then in addition, a way of specifying whether we should set site language, content language or both. Something like:

[1234: Title goes here | flag, flag, flag : flag, flag, flag]

... where the first set of flags represent the content selection and the second set represent the site interface language i.e. the path prefix/domain to be used when building the target url. (if omitted, standard behaviour would be used.)

Flags would be:

... that should cater for just about everything... Or have I missed something out?

Examples:

I need to think more about the macro idea - it might just be overkill. But, I imagine allowing defaults for Multilink defaults as flag, flag, flag : flag, flag, flag - that would be the easiest way to allow full flexibility. Then it's only a small additional step to allow the definition of other macros in the same way. So, assuming you had macros already defined for all your typical uses, links would generally be just [123: Title | behaviour] and most of them would just be [123: Title] since you would define default behaviour according to your needs.

Edit: After taking a look at the documentation again, if I don't specify and add multilink tags, the only other choice is to use the redirect submodule, correct?

Yes (if I understand the question.) Via ML Redirect the user should end up at the same url that they would have arrived at if they had clicked a ML link in the first place.

Thanks to MyXelf and vividgates for lots of useful input. @MyXelf, no #12 was not meant to confirm that anything was wrong .. the way that language ordering works at the moment is not a bug! :) What is clear is that ML is not yet flexible enough to cater for all the various use cases. Not *all* the input I have on this topic is in this thread. It's trivial to implement the change described in #6 if that's what you need.

So, v2.2+ gives absolute preference to the user's preferred language. Why would you *not* want to respect the user's language preference? It's either from their browser, or stored in their account preferences, by them, for a reason. So to my mind it's the *primary* language - if you don't have content in that language then that's a different matter - no need to *force* the user to read everything in *your* choice of language. Ok, I admit I'm biased by personal experience here, I *hate* sites that wrongly assume I want to read Spanish just because they lookup my IP address and see that I'm *in* Spain. PayPal is worse, the send me emails in Spanish, and as far as I can see there's no way I can set an option to receive them in English.

So, a simple configurable option to remove user preferred language from the list of preferences used by ML seems like a good idea. Actually the option is already configurable - it's in line#243 now :) But I'll add it into the config screen too.

From MyXelf in #15 ...

What is a preferred language? Something entirely up to the user and totally umpredictable from any logical point of view.

Agreed. At least we have a very good indication from the browser (if the user has configured it correctly.) Actually this is probably *the* best indication (much better than the account preference setting as that is only a single value.) Ok, of course this assumes they are using their own computer, or their configured account on a shared computer, but these days that's probably the case in a high proportion of cases.

The info sent by *my* browser is:
en-gb,en;q=0.7,es;q=0.3
... which means I prefer British English, then any other English, and finally Spanish. I have no idea how Firefox works out the "quality" settings (the 0.7 and 0.3) but my stated language preferences are clear.

Hi:

I was trying to save you some headache, gain time, make life easier and avoid people generating issues when your assumptions don't fit in certain situations or when your *best* behaviour wil misbehave under some circunstances. If your idea (I guess it is) is to build something that will work on the 95% of the use cases, I'll second you with this.

If I'm not wrong from #22 I can see you are starting to decline the user account preference in favor of the browser's preferred language, if that's correct then you are a bit more agree with #15. If at some point in time you forget about browser's preferred language (you are able to set your preferences, great!, but for sure a lot of people is not) and take into account the current language, then we will be talking about the same.

#20 looks good as a first approach.

Maybe I'm unable to translate my head to English and express my ideas, sorry about that.

Meanwhile don't worry I can keep patching ML to achieve my needs, even if you change the line numbers :-D

Best regards and I'm truly thankful for taking time for all this

MyXelf

If it works in 95% of use cases that's acceptable I think. The target of 100% may not be achievable in practice, sometimes patching is the most practical approach.

I do think using browser language preferences makes a lot of sense - it will work for anonymous users, and provides multiple language choices. The standard "fallback" method is inadequate in many circumstances. Please remember the primary purpose of MulitLink is to provide an easy way of inputting links to translated versions which may not yet exist. The whole discussion of language order only becomes relevant when content is not available in a user's preferred language. Then ML has to decide what version to link to, and that really should be based on user preferences, not simply "site default". So on a site where the default language is German, and some content is available in English and Spanish, I want to see English if available, otherwise Spanish, and German only as a last resort. But in all cases I prefer the site interface to remain in English - I definitely don't want it switched to German as I don't really understand German at all. I don't think the system should ever switch the site interface without specific input from the user to that effect.

Anyway, thanks again for all the input. I'll try and build it all into the next release.

Great! Can't wait to put my hands on the next release. And hoping not to have to patch, but ready in case it is needed :-D

Be cool

MyXelf

Hi, very interesting discussion. I want to comment on the ML filter (I'm not using the redirect module). Presently, ML outputs the link in the language of the user's account preference (if it's a registered user) or whatever preference is set in the browser (if it's an anonymous user). If I understand correctly, this work is already done by Drupal if the language negotiation is set to "Path prefix with language fallback". That would mean that if a user (whether anonymus or registered) is viewing the interface in another language (for whatever reason) it will always be by choice, and thus ML is not respecting this choice. Am I correct?

As I see it, there may be several reasons for an anonymous user chosing another interface language than the one set in his browser. First, in my experience, most people don't even know about this possibility :-) Second, frecuently people use a browser on a different computer. I also think that in many cases, registered users don't discover immediately that there is language preference option in their account settings. So they may just have got the default site language.

I tried the fix in # 6 and it works fine. Thanks a lot.

If I understand correctly, this work is already done by Drupal if the language negotiation is set to "Path prefix with language fallback".

The result is very similar, but the process is different - language fallback works when a page is displayed - it doesn't affect how a link is generated. With fallback, content in the site default language is shown, if the requested language (from path or domain prefix) is not available.

That would mean that if a user (whether anonymus or registered) is viewing the interface in another language (for whatever reason) it will always be by choice...

Maybe, but I don't think you can be sure - especially for an anonymous user - they may have clicked a link on another site (or maybe even your site) that gave them the "wrong" language interface, so redirecting (in the case of MultiLink Redirect) to their preferred language seems correct to me. I have already coded for the next version, a way to detect that they have chosen to switch language, and then the redirect will not happen. It works if you are using the standard language switcher block, or Language Selector Dropdown with a small patch.

... and thus ML is not respecting this choice. Am I correct?

Correct if indeed it was the user's choice, but we don't know for sure - that's the problem. Nonetheless your point is very valid - ML should always respect the user's choice, so some more intelligence is required, and more configurable options so that you can configure it to work the way you want. As I've already said, I think that preferred languages configured in the browser should be respected above all. It annoys me when sites that switch me to Spanish just because I'm in Spain - even Google does this - when I go to google.com they redirect me to google.es in Spanish (though only on the first visit, later they use a cookie to remember my site/language choice.)

I'm hoping to have some free time soon to update ML, here is my summary based on the above:

* We cannot assume that just because the user is visiting mysite.com/xx/page then their preferred language is xx - they may have arrived at mysite.com/xx/page via a link elsewhere. So, we need to get their preferred language from the browser and/or user profile.

* In general, user-preferences (from profile and/or browser) should be respected - you do not know what languages a user understands. We definitely should not switch the site interface language without specific instruction from the user.

* If the user has *specifically* switched language (e.g. from Language Selector, not simply by url) then we can probably assume that the selected language is the *preferred* language for the rest of the session - all further links and redirects (and the site interface) can then use that choice.

Hi netgenius (et al),

Firstly thanks for a very useful module and a fascinating discussion re the ins and out of letting choose their desired language.

I've been playing around with multilink redirect (MLR) and have been having fun getting my head around the way it functions, especially in conjunction with Pathauto. I've a question relating to tweaking the redirect module to achieve a slightly non-standard requirement.

Background
=========
The site in question is multi-lingual (obviously) and has no user registration. I'm using MLR to redirect a user from www.example.com/content/(nodeid) to www.example.com/(lang-prefix)/content/(nodeid) based upon their browser preferences. The users always enter this site through deep links like this and never through the "front-door".

All pretty straight forward so far - although I did have an issue with redirection (because of my lack of understanding of how the module worked) when I tried to set up redirection from www.example.com/content/(auto-generated English alias) to www.example.com/(lang-prefix)/content/(auto-generated translated alias). The user was being redirected to www.example.com/(lang-prefix)/content/(auto-generated English alias) which didn't exist. I've worked around this by switching off the auto-generation of aliases in the translated nodes.

My problem/feature request is that I'd like the user to be able to in effect change their mind and override their browser settings, and ideally I'd like this to persist between sessions. Consider the following scenario. A user enters the site through a deep link (www.example.com/content/(nodeid)) and is directed to the language node (www.example.com/(lang-prefix)/content/(nodeid) dictated by their browser settings. They're using a borrowed computer (or changing the browser settings is simply beyond them) and they change to their preferred language using the language changer and browse around happily. A short while later they deep link in to another node. I'd like to try and avoid MLR changing to the browser language version of the page and forcing them to choose their preferred language again, and again the next time they deep link in, and again, etc (and if they end their session (turn off the browser, computer, whatever) id like their choice of language to persist on that machine, although that in many ways is not as important as avoiding repeatedly changing the language throughout a session).

So where's the best place to start tweaking the code?

My first glance at the code leads me to believe that it may be around here.

 // Use user's preferred language to build the url (e.g. reset language prefix to user's preferred language).
  // @todo Maybe this should be a configurable option.
  // NB: We use the first of _multilink_preferred_languages() rather than user_preferred_language() to allow further options in the future (maybe.)
  $pref_languages = _multilink_preferred_languages();
  $language_list = language_list();

Correct?

Any pointer re how to achieve what I want to do?

TIA

Hi netgenius,

I've been having great fun with slight modifications to your excellent module to suit my (probably) unusual use of persistent language based redirection for anonymous users and am pursuing a session and cookie based solution. You mentioned in #27 above that

I have already coded for the next version, a way to detect that they have chosen to switch language, and then the redirect will not happen. It works if you are using the standard language switcher block, or Language Selector Dropdown with a small patch.

Will this be published soon as I believe that it will be a particularly elegant solution to my non-standard problem?

Sorry for being quiet for a long time.. just busy! (well, and holidays :) ... There is a lot of good input in this thread and I will read it all again carefully when (soon!) I get back to work on the module. D7 version is in the pipeline too.

Yeah! That's awesome news! Netgenius

I've started a a discussion on groups.drupal.org to try to get further input from users.

Version 2.5 is out - see http://drupal.org/node/1277026 - implements the ideas I mentioned in #31. Also allows some configuration of language preference order via settings.php, so hopefully patching will no longer be needed for most use cases. Enjoy :)

D7 version is next!

Hi Netgenius:

(Sorry for this been off-topic)

Do you have an idea when will you be releasing the D7 version? Right now I have a decision to make (keep waiting for ML to go out in a D7 version) or switch back a huge number of content-links to the traditional Markdown style (which I have been avoiding at all costs).

Thanks in advance

MyXelf

Hi MyXelf - I'm actively working on it this week, and expect that the core functions (input filter - link generation) will be working and available later today or tomorrow. Some help with testing would be appreciated (ML is quite difficult to test!). Please read and join in #1278930: MultiLink D7 version initial release.

Hi there,
i've a problem with multilink. i tryed with different combinations in $config at settings.php.

i get a redirection ERROR when i try to acces a page like this www.domain.com/node/155 when lat time i visited it was in anotehr language, i.e. www.domain.com/es/node/155

same with frontpage, i'm visting the website in spanish, multilink force me to visit everything in spanish cause i'm not using normal language switcher. then i close explorer windows ( firefox ) and try to acces to my site again www.domain.com and i get a redirect problem and cannot acces to the page till i clean cache, then when i acces the site it redirects to www.domain.com/es .

thank you in advance!

@rol:

Please open a new issue to report this problem, I'm pretty sure is not directly related to this thread. I would also suggest you to try to provide as much information as you can in order to solve this ASAP.

Thanks for reporting

MyXelf

Try logging is as admin (user-id 1) ... that will *not* get redirected due to the "bypass multilink redirect" permission. You can also give the "bypass multilink redirect" permission to a role (e.g. "authenticated users" during testing). This way, redirects will not actually happen, but will be displayed as a message instead - that should help you understand what is happening.

What settings do you want in $config? The default settings work fine in many cases.

One thing - you can manually add ?multilink=switch to the url to make multilink recognise a new preferred language,

e.g. goto to mysite.com/en?multilink=switch .. then you will stay in English and not be redirected back to Spanish.

MyXelf is right - this should probably be a new issue!