devot:eeDevoted to ExpressionEngine

I’ve been working on switching a site from Mark Huot’s defunct Simple Translator over to your Multi-Language Module, and I’ve come across one issue that bugs me - perhaps because it was effortless in Mark’s implementation: generating URLs to entries.

Typically I make use of {comment_url_title_auto_path} to link to entries, but with the language in this module being determined by the URL, that’s no longer viable.

This is in contrast to Mark’s extension, which determined the user’s language according to a cookie. No URLs were used to determine the language to display, thus leaving all the internal links from one page to another completely intact.

What are the chances of your implementing something like this, that would allow the URLs to remain intact?

hi michael. i understand that the switch to a url determined langage system might seem tricky but i’m afraid that using cookies instead is not something i am considering. allow me to explain why…

when designing this add-on a major consideration was being able to link to different language versions of a page. so for example if i go to a site that is by default in german but i am viewing an english version of a page then i should be able to copy the url, send it to a friend, and then they should see the same english version that i am seeing. with cookies they would see the german version. with the language in the url they would correctly see the english version.

another important factor is that search engines will only index the default language version of a site, when clearly you would want them to index every language version.

i hope this clarifies things a bit. in the meantime i suggest using the {base_url} global variable, so in the example you give you would use this instead:

{base_url}channel/comments/{url_title}

Ah yes, I see your reasoning. With MH’s extension, however, he had things set up so that linking to other languages remained intact; in fact, the language switching menu one would implement on a site used a URL-based method, but it was a temporary one. You’d have links to www.example.com/news/lang/_es/, for example, which would set the cookie to Spanish (ES) and put you right back on the www.example.com/news/ page, just with everything displayed in Spanish.

The search engine factor, however, is a good argument for URL-based language switching, one that hadn’t occurred to me. :p I’m sure there’s some way to work around it and have the best of both worlds… and when I figure out what that is, I’ll be sure and let you know. :p

As for the linking, we both missed something obvious, and you might want to update your add-on page with the info. The path.php has a “site_url” variable that is used when generating links using {url_title_path=“template_group/template”} (see here). If you specify that independently for each language, you can use {url_title_path} for links and they’ll work across all languages. :) Unfortunately, {comment_url_title_auto_path} still doesn’t work, since it doesn’t make use of the site_url variable, but that was always somewhat of an unintended use of that variable. :p