Multilanguage support - Add language field

We have Drupal is set up with the domain name negotiated language setting. This gives a configuration like:

* http://www.mysite.com -> English
* http://www.mysite.no -> Norwegian
* http://www.mysite.de -> German
etc

For each of these sites we have localized paths, which in some cases may be the same document, and in some cases not. For example, a page with the title "Drupal" can exist with the same path for all of the languages, while a page with the English title "Apple" would be named "Eple" in Norwegian.

The problem arises when a path is realiased (for any reason - but for example a page title change) in any of the languages, and a redirect is created from the old to the real path. If path_redirect does not take the language variable into account at this moment, the redirect will be "global" - in the sense that it will steal this path for all languages.

For example, renaming the english document from "Drupal" to "Drupal 6" will cause path_redirect to insert a redirect from the path "Drupal" to for example node/23. This is valid and correct for the English installation, but this the norwegian and german paths will break; because the other documents named "Drupal" not necesserily are node/23 - but may be a completely other documents.

1. Add language field varchar(12) not null

The workflow would be something like this;

* in path_redirect_init, the first thing that should be done is global $language and in the queries searching for redirect paths the language should be added

* For all the other function load/save/delete - language should be added (AND language = '%s') to all queries, except those querying by rid.

Changing path_redirect_init will have implications for all paths created before adding the language variable; so for non-multilingual sites, the whole path_redirect table could be updated with the $language->language variable at the same time the field is added in an update function in the install file. For multi-lingual sites using domain based language negotiation it is impossible to know for which domain a path is originally redirected; so the best thing would probably be to scrap all old redirects. My guess is that there are very few installations where this is an issue, as they (like me) fairly quickly would discover this very problem...