Those rules appear to be completely out of order. See [
webmasterworld.com...]
The problem may be that your IE browser is not configured to send *any* Accept-Language header, in which case, neither of your rewrites will apply. You need to pick a default language and rewrite to that language's files if no Accept-Language header is sent.
There's also another possibility: The browser may be set up to accept both languages -- See additional notes below.
Taking care of both of the above issues with a few additional minor tweaks, I would suggest:
DirectoryIndex index.html index.php
#
RewriteBase /
#
# Redirect to language-specific subdirectory based on the first language
# code found in the Accept-Language request header sent by the client
RewriteCond %{HTTP:Accept-Language} ^([^\-,;]+[\-,;])*([a-z]{2})([-,;].+)?$ [NC]
RewriteRule ^$ http://www.example.com/%2/ [R=301,L]
#
# Else redirect to default language (Français-Québécoise)
RewriteRule ^$ http://www.example.com/fr/ [R=301,L]
#
RewriteCond %{REQUEST_FILENAME}/index.html !-f
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^([^/]*/)*catalog/ index.php?sef_rewrite=1 [QSA,L]
#
RewriteCond %{REQUEST_FILENAME} !\.(png|gif|ico|swf|jpe?g|js|css)$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . index.php?sef_rewrite=1 [QSA,L]
There is still a problem here, and one which may require re-thinking your entire approach.
An example a typical "Accept-Language" header may look like this:
"fr-ca;q=0.8,fr-fr;q=0.7,fr;q=0.6,en-us;q=0.5,en;q=0.3"
This says that the Canada dialect of French is preferred most, followed by the France dialect, followed by any other country or regional dialect (e.g. Algeria), followed by U.S. English, and then by any other dialect of English.
Neither your original multi language-rule code nor my single-rule code addresses this priority; If the first-tested language code is found *anywhere* in the Accept-Language header, then that language is selected.
Then there is the 'blank Accept-Language header' problem already discussed.
At an even deeper level, the Accept-Language headers sent by a browser do not necessarily reflect the actual language preferences of the user. The user may have never set these preferences. They may be blank or still set to the factory default. If the user has multiple browsers installed, they may even be set differently. In addition, what about internet cafes and airport and hotel internet-access kiosks? Schools? Libraries? Government and business offices? Any place where the user does not "own" the computer is problematic.
Really, a better approach is to let the user select his/her preferred language using the "world map" or "rows of tiny flags" methods on a bi-lingual or multi-lingual home page.
If you want to continue to try to user client-provided language preferences, I suggest that you redirect all login-page requests to a script which can properly-parse the Accept-Language headers by checking the "preference-weighting factors" of each indicated language, and then generate s proper redirect response.
If the Accept-Language header is blank, you can also look at the browser user-agent string (for example, Mozilla and Safari-based browser (e.g. Safari and Chrome) user-agent strings contain a language- and optional country-code indicating the localized version of the browser which was installed.
But either way, using the "world map" or "tiny flags" method will be needed to address the fact that neither the computer OS nor the browser may actually be configured to reflect the actual user's language preferences.
Also, get rid of the <IfModule> test. All it does is to cause this code to fail silently if mod_rewrite is (or becomes) unavailable, or it wastes CPU time by testing for that module's presence for each and every HTTP request received by your server.
Jim