Problem/Motivation

I have setup a multilingual site for the first time using language negotiation of 'Domain name only' and am confused with regard to how I should/will administer the site (I am referring here to user/1 tasks, not general content administration). What am I observing:

I have to login explicitly from each domain (perhaps necessary due to cookie requirements per domain?) in order to reach admin pages within the separate domains
When I explicitly navigate (type the URL) of an admin page in a non-default language, all admin links still point back to the default domain. If I submit a change I am redirected back to the default URL (i.e. away from the Spanish URL)
I never see the site's admin pages in any other language aside from the default (English). I have setup multilingual sites before and am sure that the interface was chopping and changing between languages (as I expected) as I moved between config changes in the other languages.
If I go to the 'site information' page on the site in both the default language and the additional (Spanish) language and look at the 'default from page' field, the site URL remains unchanged (remains the default) on both but if I do this from one of my other sites that is configured to use 'path prefix' I see the prefix in the URL for the other languages.
If I go to the /admin page under each language and scan the URLs on the page, they are all the same whereas on another site I have created with language prefixes they contain the language prefixes.

I have created a brand knew site with the following core and modules:
- Drupal 6.22
- XML Sitemap 6.x-2.0-beta3
- Admin menu 6.x-1.8
- Internationalization 6.x-1.9

Of course, I may be doing some rather silly but I can't see anything. Should I be adding additional settings.php files? Should I be administering the site from separate language admin accounts?

Please, where am I going wrong?

Regards

Adam

Comments

anea02’s picture

anea02 commented

As an update to this - I have built an entirely knew site using versions of Drupal and modules that I have used for other sites in the past (just as an experiment):

- Drupal 6.19
- Admin menu 6.x-1.8
- Internationalization 6.x-1.5

It all worked perfectly.
As a simple example:
In the first install with all up-to-date modules, on the home page, if I changed between the two home pages the displayed language would not change. If I do this now on the install based on the older code base the language changes as expected.

I will upgrade each module one at a time (i18n and Drupal core) and see if I can now break it.

Of course it could all still be a configuration error in the first case in which case my monologue is going to look pretty silly ! :-)

Adam

anea02’s picture

anea02 commented

OK, I have upgraded core and Internationalization to the latest releases but cannot recreate my original issue.
I have checked for differences between:
- httpd-vhosts.conf
- .htaccess
- settings.php
- All language configuration option (negotiation, content selection mode, built-in interface translation percentage ...)

I cannot see any differences. I will do yet another rebuild with only the latest versions to see if I can recreate the original issue.

Adam

anea02’s picture

anea02 commented
Project: Internationalization » Drupal core
Version: 6.x-1.9 » 6.22
Component: User interface » language system

Did another rebuild this time with all latest - core and modules, as above and recreated the problem. This time I also used the original domain names I had used when I had experienced the issue initially (for my 'old version' test, which had no problems, I used a couple of simple, fictitious domain names).

This time though I managed to solve the issue - the domain names stored in the 'Language domain field ( admin/settings/language ) are Case Sensitive.

Perhaps I should have tried this initially (I hear 'a number' of you say) and hindsight is a wonderful thing. I guess I am not used to domain names being case sensitive (i.e. they are not).

Could I be so bold as to suggest that this be changed such that the field is not case sensitive? OR a large comment that says not only do you need the protocol prefix but also that it is a case sensitive field (IMHO - less desirable / incorrect solution)

I have moved this to core as I think that is where it belongs. I have not made it a bug simply because perhaps there is something I do not as yet realise about the reasoning behind this field. If someone from 'core team' thinks it should be a bug or a feature request...

That's the last time I use camel notation to try and ensure I don't make a typo (LOL - and I didn't!)

Regards

Adam

Status: Active » Closed (outdated)

Automatically closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.