Products » Support Forums 

Support Forums

HomeHomeDotNetNuke Modu...DotNetNuke Modu...Url MasterUrl MasterDNN 5.2.1, UM and multi-language URLsDNN 5.2.1, UM and multi-language URLs
Previous
 
Next
New Post
1/12/2010 7:25 AM
 

Hi Bruce (or anyone who runs UM and a ML site),

I have read a lot of posts in your forums about ML urls with UM and wanted a summary if possible:

Basically I want to keep all my normal, existing URLs for the english culture (US). If Spanish is enabled, I want to have something like "lang/es" in the URL (so the English version is the "default") - there seem to be 4 different tools to use to localize pages/keywords (my top priority is for SEO) etc:

  1. EALO
  2. Apollo
  3. Adequation (which uses a duplicate content approach)
  4. DSLocalizator 

I got the impression from some other posts that DSLocalizator messes around with URLs and is beta. I have a lot of custom modules so I am not sure duplicating every single page for every single language is feasible (Adequation). Hence I am looking at Ealo and apollo.

My question is - does UM play well with these? Anything I should be aware of before starting to implement it? I want to keep all the existing english URLs without the language param in it, and then apply the same 301 redirect rules for the spanish version but with the localised URL . I am a little confused about whether is it possible to do this WITHOUT having lang/es in the URL - as long as the URL was different it would not cause duplicate content in Google, BUT some pages might have the same name (like userprofiles) with 2 different sets of content (ie. the menus would be in Spanish). So maybe for this reason it is important to always include the lang/es for non-english?

Any advice appreciated - this is a new field for me...

ps - this thread was quite interesting: http://www.ifinity.com.au/Products/Support_Forums/forumid/8/threadid/1806/scope/posts

 

 
New Post
1/12/2010 7:57 AM
 

egads - that thread is almost 12 months to the day, and I still haven't released the ML changes.

To answer your question, I haven't yet tested directly against the apollo module, I have verified it works OK with the adequation module, and when I last looked at the DSLocalizator, it wasn't working exactly correctly, though some people report getting it to work OK.  The problem with the DSLocalizator is that, for me, it did excessive modification to the core, and so will probably fall out of compatibility pretty quick unless it's well supported with each new release of DNN.

I do have a beta running of the ML stuff, and it does most of the things I said in that other thread.  Not sure on your timeframe for ML changes but as you have a proper test site perhaps you can have a look at an early beta.  The biggest problem for people is that as soon as you turn on ML, all of your existing pages tend to get duplicated with the language/en-US Url, and it turns into a bit of a mess.  My changes get around this by assuming the language parameter for the default language, and removing it if supplied.  It uses the 'other' (ie, non-default) languages, but gives you the ability to name a page differently (provide a different url, ie /beer, /bier and /cerveza ) which will drive the language parameter rewriting behind the scene.  I have further work to do on the portal alias side, so that .com , .fr, .de etc can drive the language parameter as well, all on the one portal and without creating duplicate content. 

To be honest the most difficult thing about all this is coming up with an interface that makes logical sense for a user.  And that's why it hasn't been released yet.

 
New Post
1/12/2010 4:23 PM
 

Ok, thanks for the indepth answer. My timeframe is now ;) (I have had the Spanish version of PokerDIY on my list for 2 years!)

Can you send me the beta and I'll try it on my test site?

I like the idea of NOT having the language in the URL but what about user-generated URLs/pages - like profiles? Unless I prefix them with something that can be localised but I did not want to do that... the only thing that would change on these pages would be the interface of course, content would all remain the same.

I don't mind a simpler solution of having the default (Eng in my case) with no extra params, and then Spanish could have the /ES/ in it. Apparently Apollo allows you to do it on a page-by-page basis (because you dont want to wait to translate your whole site to go live, I want to do it page by page to get indexing benefits.

Like all the other cool stuff you are working on, this would be huge too ;)

 
New Post
2/5/2010 5:48 AM
 

Hi Bruce,

Ok, I am working on the translation stuff and ready for the next step (I had not looked at it in a while). Can you send me the beta please? (I am not sure if I am getting your emails so please confirm here).

Basically, I want the default (en-us in my case)- to keep the URL the same. Then I want es-es (spanish) to add lang/es-es to every URL, BUT ONLY when that page is enabled (I THINK this is an Apollo thing). I need to enable pages one at a time. If you were in es mode and requested a page that was not ready you would get the en-us URL and content - this would avoid duplicate content issues in Google.

There is a new setting in DNN 5 (I think) under Host: Enable Content Localization? - "Check this to enable passing the users current culture allowing for dynamic portal and content localization" - this sounds interesting but it is essential the URLs change per language.

Under Languages -> Language Settings there are 2 more settings:  Enable Language Parameter in URLs? - this adds "language" to the URL - I would prefer "lang" or something customizable or even just "www.pokerdiy.com/es-es/profile.aspx" ideally for example.
How does this setting fit in with your changes?

So my main concern is getting the URLs right. How close are you to this?

ps - I asked Erik from Apollo about his modules.

 
New Post
2/5/2010 1:40 PM
 

I will get the beta for you in about a week or so.  It's a while since I last worked with it and I have the merge back in some of the latest bugfixes to the code base and make sure it is all working.

The code for the language urls is complete, just needs thorough testing in real world situations.  It will support complete removal of the language parameter for the default language, and should be able to have a simple culture id (es-ES) in the Url instead of the 'language' parameter for all other installed languages.  You can also supply a native-language conversion of the page Url which will automatically rewrite the url with the language key/value pair in it.  ie Hello.aspx = &language=en-US while hola.aspx = &language=es-ES.  Both of these Urls (hello.aspx/hola.aspx) will return a 200 so it's vital that the content on the page is actually different so you don't get duplicate content.

I think the best idea will be if I can have a go at the test site again and check to make sure everythign is working OK.  I haven't done much work with the Apollog stuff as yet, but it's my intention to make sure it's 100% compatible with Apollo to start with, and some others as I go along.

 
Previous
 
Next
HomeHomeDotNetNuke Modu...DotNetNuke Modu...Url MasterUrl MasterDNN 5.2.1, UM and multi-language URLsDNN 5.2.1, UM and multi-language URLs


Support Guidelines.. Please read before posting

To get support on iFinity products and services, please search the forums for the the answer to the problem you are seeking. If you cannot find a solution, post a question in the relevant forum.   Ensure that you specify the relevant versions of the problem, and the actual error message or a detailed description of the problem.    You will need to register with this site to post on the forum.  If you have a Microsoft Live (Hotmail/Passport) account you can use that.  If you have a Open Id account you can use that.  If you neither of these, you will need to register a user Id and password.

Please note : If you are posting a new thread for the Url Master module, please include the following information where applicable:

- Url Master version

- DotNetNuke version

- Example Url where possible

- If there is an error, please post the full error text and/or stack trace (from the DotNetNuke event log).