multilingual in 1.4.3 beta

bic

I'm testing 1.4.3 in my local wamp environment and I am seeing 302 redirects every time I click on a link with seo locale enabled. That's because every link generated by zenphoto has the language prefix (not the subdomain). Is that really wanted?

bic

The prefix is added in rewrite_path() function.
`
if (class_exists('seo_locale')) {
return seo_locale::localePath() . "/" . $path;
`
I suppose this is needed only if the subdomain option for dynamic locale is enabled. Am I wrong?

acrylian

I am not sure about the 302 error which seems wrong. The subdomain usage and the locale in the url are two different ways for the same purpose.

Since searchengines want "fixed" urls for different languages we added those two. The locale in the url (www.domain.com/<locale>/<path>) is older and was actually just meant for switching the language. Zenphoto does itself not need the fixed urls but when made we forgot search engines do... So now the <locale> part is within the url although not really part of the path.

The subdomain way is new for 1.4.3 so you have really different urls respectively sites for different languages.

So in short the above is used for both. But sbillard is the author of it so he might be able to tell more.

bic

Yes, may be is just needed one condition more in rewrite_path():
`if (class_exists('seo_locale') && "option subdomain enabled")...`

I'll wait for sbillard feedback and then I'll open a ticket, because all those unneeded redirects for every single link in zenphoto are really too bad.

Of course you can still have the lang prefix in sitemaps.

acrylian

Well, the links using this are in fact redirections as the locale in the url actually only switches the language. Before this it was not always in the url so www.domain.com/<album> would have been for any language you provide. This would cause search engines to count those as "duplicated content".

Therefore on user request we made them static and also added the subdomain way.

Again, Zenphoto sets the language via gettext and cookies/sessions so it itself doesn't need any language part in the url. We cannot change it completly as that would possibly break quite a lot of things.

However, 302 means "found" respectively "moved temporarily" so it seems fitting for this purpose (sorry ,confused it when answering above some how)..

bic

This scenario works perfectly with subdomains, because then you have real URls and no content duplicate. But what about the old prefix scenario? I can't see any real advantage, because at the end of the game the search engine is redirected to the same page for every language. It may appear like a cheating behavior.
Also it introduces unneeded waiting time for real users, because of the double server request.

It could be different if it was possible to introduce cookie based rewrite rules in htaccess, to have really different URls also without subdomain enabled.

I am not able to implement it, but look at this example:

`
RewriteBase /
RewriteCond %{HTTP_COOKIE} lang=([^;]+) [NC]
RewriteRule ^(.*)$ /$1?lang=%1 [NC,L,QSA]
`
May be it's possible to get something similar working with zenphoto.

acrylian

Well, the subdomain way was introduced because of the "duplicate content" issue.

You can actually also append lang=<locale> but that is not what Search engines recommend. But as said it is used for switching, you don't need to in the url afterwards.

bic

No, of course I've taken that example just to show how it is possible to have rewrite rules based on cookies, that is the way zenphoto manages languages.
May be it's possible to add the lang prefix (domain`/en/`album/image.php) with a rewrite rule based on language cookie, to have 'real' URls also without the possibility to buy a subdomain.

acrylian

Ok, I see. Sounds like an idea. You could open a ticket if you like.

Regarding subdomain. The shared host often have a number of sub domains included.

sbillard

You do know that this plugin is optional, don't you. If you do not want these kinds of URIs disable the plugin. It is actually prefered that you use the domain based language URIs (`fr.mydomain.com`) anyway as this has much better performance.

Making the rewrite rule is not practical. The actual languages supported are selected by options, so the list is not a constand. Rewrite rules require constant conditions. And a rewrite rule based on the cookie would be pointless. These language strings need to be in the links that search engines follow to be effective. They are not at all needed for the language to be displayed.

Anyway the purpose of the plugin is to recognize and add those language "folders" to the URI. It seems counter intuitive to therefore have an option to omit them--just disable the plugin.

bic

Edit
I'm reading now your message sbillard...

Ok, I understand you point about rewrite rules. I'm aware of the way zenphoto manages languages and I know that URls are not actually needed. I'll make further investigation about the rewrite rules based on cookies, that was just an idea, may be useless, may be unpractical.

I have seo locale enabled in live site because google was indexing only english pages, for the reasons we know, so I needed a sitemap with URls based on language. I still need this feature, what I don't need are the useless redirects that have been introduced in 1.4.3, and can be removed without any new option, just adding the condition I suggested to rewrite_path.
This doesn't change things for people with subdomain option enabled, just live thinks as they were before for people without subdomains.

bic

I really can't understand this point:

Anyway the purpose of the plugin is to recognize and add those language "folders" to the URI.

So what has been doing the plugin until now?
I've always used it to recognize the URI, not to add them. Also because the adding feature was not present before. It is still not present in latest stable release. And, to my eyes, it's only needed by people with subdomains enabled.

I consider a big step forward this new feature, and I'll see what I can do to get some subdomains enabled by my hosting company.

However I can't see the reason to add the prefix if the subdomain option is disabled.

sbillard

You do know that if you do not like what a plugin does you do not have to use it. That is always your choice.

Have you read the documentation? "`This plugin should not be used if you are using subdomain locales (See the dynamic_locales plugin.)`"

Anyway, I am not going to argue with you. The plugin does what is is intended to do. That will not change.

bic

sbillard, I was just trying to be helpful, but it's always hard for me to be understood by you. Keep in mind that english is not my native language, but remember also that more than once I've found bugs or problem in zenphoto that I wasn't able to explain to you without some misunderstanding.
I apologize for that.
Of course I can still use the plugin and disable adding the prefix in rewrite_path, it's not a big deal to keep track of it in future updates.
Thank you anyway for your work on zenphoto.

acrylian

We have here the common problem of misunderstandings that even adds up if not a native speaker (as you know probably I am none myself).

The seo_locale always did provide the way to switch the language via the url addition. It was used once and did not show up always. That it stay is indeed new because seo likes it so the links are different. Since Zenphoto is not initially setup to have that in the url and changing that is far too complicated this was added as a compromise. Of course customizing is always possible which is why we are open source.

With grown systems you always need to be careful if changing base functionality as that can break a lot even unexpected.

Far better is the the subdomain way which was added for that reason we added as an alternative.

bic

I'm afraid i didn't like very much sbillard's approach to the problem.
First of all because it make no sense to say "if you don't like the plugin then just do not use it". Of course the same can be said about zenphoto, that I like indeed very much, so what's the point? He feels I offended him somehow? If so it was not my intention, and I apologize again for it.

As far I understand from your explanation this compromise is just adding the lang prefix to generate a sort of 'fake' navigation inside zenphoto for web crawlers. My point was, and remains, that for that 'fake' URl was indeed enough the sitemap with the lang prefix. The side effects introduced by the new rewrite_path function are not acceptable imho in change of (probably) nothing.
Before we were "cheating" just in sitemaps, now we are "cheating" all over zenphoto, at the price to have 302 redirects for every link.

The subdomain approach is of course much better, and I'll try to setup my site for that, however I still think that was better to live things as they were before for people not using subdomains.

What else, I understand that you are doing a wonderful and hard job on zenphoto, and that you are may be under pressure for the next release to come.
So, sorry for sharing my opinion with you if this is somehow irritating someone of you.

acrylian

I cannot speak for my colleague but sometimes comments (not specifially yours!) come over a little demanding... and sometimes it adds just up if answering inbetween. Sorry if that sounds a littlte to harsh at times. We appreciate ideas and everything but sometimes are probably caught on the wrong foot (as we say in German).

As far I understand from your explanation this compromise is just adding the lang prefix to generate a sort of 'fake' navigation inside zenphoto for web crawlers.
Right, that's what it does, just for switching. We had added this statically because of an longer discussion about this not being accecpted or correctly working because of the fake links.

Even if we used htaccess based on a cookie (we did discuss about that yesterday) we still would have the redirection internally.

When we introduced multilingual - we probably must admit that - we made it convenient for people and not so for search engines. The subdomain way is an attempt to over a properly working way.

bic

So until now seo_locale was useless for seo purposes, even if used side by side with sitemaps. And of course, if this is true, I can also disable the plugin.

I've obviously missed your discussion about that, I suppose that the developing team is totally sure that now seo_locale (subdomains disabled) will became more friendly for search engines.

Regarding humans (as we are after all) I can add some data to the discussion. My local server response time, with the new redirects, increases by about 150 ms. I suppose that in a live scenario the waiting time should increase more and in not predictably way, depending on connection quality.

My idea about htaccess and cookies is probably totally wrong and impossible to implement, but I meant it to have a different behavior.
The idea was to redirect to folder like based urls (en/it/de...) depending on dynamic_locale cookie. After that no more internal redirects should be necessary. Of course there would be a lot of changes to do in the core, and I have no idea about how to set default language and/or http accept language.
So just forgive me and forget this idea.

acrylian

The seo_locale was more a workaround. There was an discussion about language content not indexed a while back (could have been months). Don't remember where and who was involved.

Your idea sounded good but will not work that way with Zenphoto without changing all completely. Zenphoto urls don't have that extra folder so you always need to redirect. Without that littlte trick the <locale> in the url could be misunderstood as an album of that name.
Sbillard is the author of that so I need to trust about that not working for us. I am not familiar with all code parts (and he vice versa, too).

I suggest to try the subdomain way. It has not been tested or meant for this but maybe the cloning that will be introduce with 1.4.3 that allows to run different independent Zenphoto sites with one core could be used as well for this. But as said not meant or tried with this scenario.