URL Rewriting Translation

[Phil]

Hello,

I don't remember if we already talked about the idea to translate
URLs.

Currently, when editing an item, we can translate title, description,
but not path to item.

I think it could be logical, if the page content is in another
language, to have a path in this langague too. And last but not least,
with actual system, Google cannot state there is 2 differents pages if
they have the same complete path... and then it may not keep noth
versions.

Is there any problem about doing this? Your opinion?

Phil.

[Alexander Obuhovich]

We have language in url too, so that's not a problem for google right now.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Dmitry Andrejev]

Hi Phil,

To be honest I don't see much benefit from this, plus it will add whole lot of complexity which I don't think we need.

Yes, Alex is correct - we have current Language (if not primary) included in the URL.

DA.

[Phil ..:: domicilis.biz ::..]

well, my matter is not to have the lang written in URL, but better to
have consistent URL. If the content is not the same language as url is
written, it's could not be so good for SEO.

I'm not a google guru, but in commercial view, i'd prefer a page link
in my language...

2010/3/18 Alexander Obuhovich <aik....@gmail.com>:

[Alexander Obuhovich]

Also not all browsers support non-ascii chapters in url.

[Phil ..:: domicilis.biz ::..]

well, I didn't thought about non-ascii caracters, here is my idea :
for a multilingual website, you need the following things:

- multisite option to bring back foreign language domains to the
website, showing by default the selected language (example: typing
inportal.ru will display inportal.com with russian as first language,
while use can still clic to change the lang of course)

- translate all the content, in my previous example, I'll translate
from english to russian. With actual system, I'll have pages encoded
in russian, according to the lang pack, page content in russian, page
title in russian, but page url will stay in english (or worst, page
path in french for latvian visitors if you prefer ^-^)

I bet this could be better to have all content with the same language,
is it a stupid way of thinking? the most important for a website is to
be seen, that's why I insist about optimizing for SEs...

2010/3/19 Alexander Obuhovich <aik....@gmail.com>:

> To unsubscribe from this group, send email to
> in-portal-dev+unsubscribegooglegroups.com or reply to this email with the
> words "REMOVE ME" as the subject.
>

[Alexander Obuhovich]

Here are some questions:

1. in case, when I have 2 different urls to one product on different languages, then what should happen, when I visit product page and change language:

• i will end up on same page with language only changed in url
• i will end up on completely new page on different language (different url I mean)

2. how should I parse url of page in case of 2-nd variant of 1-st question: search on all languages?

[Alexander Obuhovich]

Better way is to make all urls appear in primary language of site domain no matter what language user have selected for that domain on front-end.

[Dmitry Andrejev]

In my opinion, the situation that Phil has described is ONLY applies to the site that uses Site Domains (new feature).

In this case it makes sense to have Multi-lingual URLs without the Language part in it. In all other cases it will make Google think it's a duplicate content.

DA.

To unsubscribe from this group, send email to in-portal-dev+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

[Alexander Obuhovich]

Exclude language from url based on domain that's a risky move, because we can have urls of different pages on different languages match leading to incorrect page to be shown based on url.

[Phil ..:: domicilis.biz ::..]

Dmitry, Alex,

your post make my idea clearer: yes, it's definitvely good using
multisite option, but even with one website it's good, here's why:

0. About duplicate content, if the URL appear in a 2nd language, it
means the content is also in this 2nd language, so no duplicate
content, but rather double content for all pages, gooood for SEO :-)

0.5 Alex, I never thought about removing lang from URL, it's really
good to have lang + path in this lang + page content in this lang.

1. when you visit a page, even with 1 domain only, you have:
http://www.site.com/catalog/product-detail.html with english content

and when you clic on "french" you could have
http://www.site.com/french/catalogue/detail-produit.html with french content

2. search can be made on all languages, and I'll test google site
search soon :-)

what do you think guys? any thought on seo side?

2010/3/19 Dmitry Andrejev <dand...@gmail.com>:

[Alexander Obuhovich]

So your answer is 2 on both my questions:

• change url completely when we are on product detail page and are switching language
• try to scan for product/category name on all languages to match url
  

[Phil ..:: domicilis.biz ::..]

yes, that's it, URL change completly.

"try to scan to match url", sorry I don't get this, URL aren't
pre-defined in system?

2010/3/19 Alexander Obuhovich <aik....@gmail.com>:

[Alexander Obuhovich]

For ex. we have 5 fields in db for product name url part in each language and we have 5 fields in db for category path on that product for each language. When I have url like "/language/category1/category2/product_name", then I should do what of two:

• look only in category/product field that matches given language (from url)
• look on category/product fields from all languages
  

[Dmitry Andrejev]

I would do 1 "look only in category/product field that matches given language (from url)".

NOTE: of course language that is Primary (not to forget about Site-domain part here).if no language in URL specified.

What you think?

DA.

[Phil ..:: domicilis.biz ::..]

For me, the better option will be the faster one.

As a website in multilanguage will have probably more visits (even
more with multisite), I prefer to focus on db requests speed, do u
agree?

2010/3/19 Dmitry Andrejev <dand...@gmail.com>:

[Dmitry Andrejev]

Just want to make sure that we are clear on the task here.

1. In Regular setup -- we should use ONLY Current language (or Primary) Filename to Parse and Build

2. In Multi-site setup -- we should use ONLY Current language (or Primary) Filename to Parse and Build

In other words it's the same approach which is 100% related to the currently loaded language 

Please correct me if I am wrong.

DA

[Alexander Obuhovich]

In other words we actually can have 3 versions:

1. build url using current language
2. build url using primary language from site domain
3. build url using primary site language (as it works right now)

--
Sent from my mobile device

[Phil ..:: domicilis.biz ::..]

My idea is the 1st option, here's why:

- using current language, URL stick to content language everytime,
wether using multisite or not

- using current language, we can have users who have found your
website from an english search, but would be pleased to discover that
they can surf your pages in japanese

- using current language, we don't have to think about multisite or
not, this would become part of the url rewriting kernel

What do you think? If you have time, you could do some "Competitive
Intelligence", and see that from the beginning of 2010, we are adding
bunch of new features never seen elsewhere ;-)

2010/3/20 Alexander Obuhovich <aik....@gmail.com>:

[Dmitry Andrejev]

Alex, Phil,

To make sure we are on the same page - let's list URLs how they will LOOK and WORK. Alex would you please do so since you can make sure technical part is covered and we don't miss anything.

The reason why I am bringing up the idea that Regular Single website and Sites Domain one will have different Primary language.

Example, as Site domains we can setup:

1. I can have Cameroon.Africa.com with French as primary which means it will NEVER be included in URLs

Cameroon.Africa.com/category-in-french.html

Cameroon.Africa.com/english/category-in-english.html

2. I can have Africa.com with English as Primary lang., but French will be available as well.

Africa.com/category-in-english.html

Africa.com/french/category-in-french.html

DA.

[Alexander Obuhovich]

You got idea completely Dmitry. Nothing to add for me here.

But I'm still insisting on admin configuration option to have selector like:

1. build url using current language
2. build url using primary language from site domain
3. build url using primary site language (as it works right now)

For example if I want site domain url to be build on specific language, no matter what language user have selected. Maybe user don't want to different url on different language, because all it's url on other then primary languages were indexed by google and won't work after what you propose is enabled.

[Phil ..:: domicilis.biz ::..]

Dmitry, it's exactly that :)

Alex, I didn't understoud at first you were talking about a selector,
of course it's always better to have the choice !

But 2 and 3 aren't the same, if we consider multisites as websites themselves?

If I'm on the 2nd website, using primary lang from sitedomaine should
be the same as primary site lang, as this 2nd site have is own
existence, do you get what I mean? and if we want primary lang for 2nd
website being the same as base website, we just have to setup the same
lang. in sitedomain.

I ask you this to simplify admin options, when we can.

2010/3/21 Alexander Obuhovich <aik....@gmail.com>:

[Alexander Obuhovich]

3rd is using primary language set on main site (in Regional) section no matter what primary language on site domain is set

[Phil ..:: domicilis.biz ::..]

I've understoud this, but this option is used to override your own
admin setting for site domain lang, right? I'm not used to override my
own choices ;-)

2010/3/21 Alexander Obuhovich <aik....@gmail.com>:

[Alexander Obuhovich]

I see now, 2nd and 3rd are the same, when you have 1 site domain or you have no site domains at all. Then 2nd+3rd options merged will be named: "build url using site domain (use site, when no site domain matched) primary language".

[Phil ..:: domicilis.biz ::..]

that's it !

you can label it "build url using primary site language"

(we won't place hints for multisite in all options, docs and support
companies are here for that ^-^)

2010/3/21 Alexander Obuhovich <aik....@gmail.com>:

[Alexander Obuhovich]

Summary:

Configuration Option Name: "Language Used for URL Building":

• site primary
• user selected (or "current")
  

[Dmitry Andrejev]

Good work guys!

I think we finally nailed it :)

I would name variable a little differently if you don't mind:

"Build URLs using":

- Site Primary Language (default)

- User Selected Language

Alex, you can call the variable whatever you think is appropriate in the back-end (code).

Let me know if agree on this.

DA.

[Alexander Obuhovich]

ok.

[Phil ..:: domicilis.biz ::..]

I'd suggest the following naming:

- site primary lang only (technically, url will never change their naming)
- current language (url will be as user entered it, and when he change
language, url changes accordingly)

Are you ok guys?

2010/3/21 Alexander Obuhovich <aik....@gmail.com>:

[Dmitry Andrejev]

Hi Phil,

I like these more since they are specific enough:

Build URLs using:

- Site Primary Language

- User Selected Language

Is any of these option unclear to you or regular user?

DA.

[Phil ..:: domicilis.biz ::..]

that's it, seems clear. Using second option will transform item path
in multilingual field.

I just don't know if this should take place in core or in multisite,
as we talked about both in our discussion. Alex, any idea?

2010/3/23 Dmitry Andrejev <dand...@gmail.com>:

[Alexander Obuhovich]

It will be in core as I've described in that other discussion.

[Phil ..:: domicilis.biz ::..]

allright

2010/3/23 Alexander Obuhovich <aik....@gmail.com>:

[Dmitry Andrejev]

Alex, do we have a task on this?

I think we don't.

DA.

[Alexander Obuhovich]

No task, please create one.

[Dmitry Andrejev]

Here is a task for this:

638: Language specific ModRewrite URLs

http://tracker.in-portal.org/view.php?id=638

DA.

[Alexander Obuhovich]

It's too early to schedule that one to 5.1.0, I'll move it to Future for now.

[Dmitry Andrejev]

Okay, how about 5.2.0?

I don't think it's very critical anyway.

DA.

[Alexander Obuhovich]

ok