There is a separate "primary" site (in another system [NOT Drupal]), and the Drupal site has two servers with one database on one of those servers connected to both Drupal instances. Our problem is with the two Drupal servers and DNS (domain/subdomain) settings to manage them.
One instance has a minute-by-minute CRON job running to keep the other in-synch, with rsync. Only one of those servers is open to login and edit with a subdomain pointing to it directly on the network. The other server has a read-only user setup for the database connection, just as a precaution.
The site is running i18n/Internationalization with "Domain name only." setup as the configuration. If someone is on the primary site, German, they will click a link to be taken to the Drupal CMS on the "www2.domain.de/page-name." While the main site is "www.domain.de," the Drupal site is "ww2.domain.de."...
Main site (multi-language WWW.domain.de) > Drupal (multi-language, i18n WW2.domain.de).
The reason for the "WW2" is to keep the Drupal site(s) separate from the primary site...
Here are our perceived problems:
To edit the CMS, you will visit "cms.domain.com." However, we are unable to edit the "site name" without switching over to the "ww2.domain.de" site... which isn't "cms.domain.de." We cannot switch the translation language to change the site "SLOGAN," and a few other "multilingual variable[s]" into German. It still shows us English. We CAN use the "Translation Interface" to edit most strings and other variables, like menus, etc.
Is there another way to edit the "multilingual variables" without having to override Drupal and wrap a string with the t()?
Also, our translated strings seem to be reverting to the English. We're checking on the synchronization, but is it possible that the translated strings could be reverting in some other way?
Thank you!
WEB SERVER Apache/2.2.3 (Red Hat)
PRESSFLOW 6.14
MYSQL DATABASE 5.1.38
PHP 5.2.10
PHP MEMORY LIMIT 128M
Modules Enabled:
Admin (admin)
Admin Role (adminrole)
Administration menu (admin_menu)
Backup and Migrate (backup_migrate)
Block (block)
Block translation (i18nblocks)
CCK Teaser Field (cck_teaser_field)
Chaos tools (ctools)
Color (color)
Comment (comment)
Content (content)
Content translation (translation)
Database logging (dblog)
Date (date)
Date API (date_api)
Date Popup (date_popup)
Date Timezone (date_timezone)
Devel (devel)
Fieldgroup (fieldgroup)
FileField (filefield)
FileField Insert (filefield_insert)
FileField Sources (filefield_sources)
Filter (filter)
Finder (finder)
Finder Autocomplete (finder_autocomplete)
Finder Views (finder_views)
Google Analytics (googleanalytics)
Help (help)
Image resize filter (image_resize_filter)
ImageAPI (imageapi)
ImageAPI GD2 (imageapi_gd)
ImageCache (imagecache)
ImageCache UI (imagecache_ui)
ImageField (imagefield)
IMCE (imce)
IMCE Wysiwyg API bridge (imce_wysiwyg)
Internationalization (i18n)
Link (link)
Locale (locale)
Menu (menu)
Menu Attributes (menu_attributes)
Menu translation (i18nmenu)
Node (node)
Nodewords (nodewords)
Number (number)
Page manager (page_manager)
Page Title (page_title)
Panels (panels)
Path (path)
Path redirect (path_redirect)
Pathauto (pathauto)
PHP filter (php)
Rules (rules)
Rules Administration UI (rules_admin)
String translation (i18nstrings)
System (system)
Taxonomy (taxonomy)
Taxonomy translation (i18ntaxonomy)
Text (text)
Token (token)
Token actions (token_actions)
Translation table (translation_table)
Trigger (trigger)
Unique field (unique_field)
Update status (update)
User (user)
Vertical Tabs (vertical_tabs)
Views (views)
Views content panes (views_content)
Views translation (i18nviews)
Views UI (views_ui)
Workflow (workflow)
Wysiwyg (wysiwyg)
Comments
Update
Update: We have confirmed that the second server is using a read-only user for the database shared by both.
I have been using the "Translate Interface" to translate strings, and noticed translations reverting to English. This is very odd, and now I'll try again to see if it reverts after verifying the read-only user. Hopefully the translations will "stick" now, and I can't imagine why they would revert unless the second server was overriding something in the DB.
Thanks! Any response will be helpful...
Kevin Davison, Web Development Manager
Another update...
Translations are FINE now, and some issues resolved by simply re-saving menus or making sure the language setting was set properly in blocks.
Now the primary issue is with "language fallback" failing with "Domain name only" in most A-grade browsers. This doesn't seem to work for German, at least.
This topic seems to cover the general problem:" language_from_browser() doesn't parse language tags correctly, has a broken logic"
http://drupal.org/node/221712
Component: language system
Perhaps the patch will work, and I'm trying to find out if there's a release to fix this asap. Can anyone help ($$) in the meantime?
Kevin Davison, Web Development Manager