Problem: $this->alias = JApplication::stringURLSafe($this->alias); does always use the current language and not the language of the article/menu/item itself
Labels |
Added:
?
|
Category | ⇒ | Multilanguage |
Hello,
you have a valid point here, but I think, if we use the default/current language als fallback, we should be save here:
1. check if content language exists
2. otherwise use current language
or we could enforce, that the language have to exist, when we create a content language
or we could enforce, that the language have to exist, when we create a content language
Nothing is written in stone, but that was the way Andrew Eddie saw it in the 1.6 pre-release times, i.e. to be able to create a Content Language before getting a language pack.
Status | New | ⇒ | Expected Behaviour |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2015-11-12 14:02:17 |
Closed_By | ⇒ | brianteeman |
Based on the comments above by @infograf768 I am closing this as the expected behaviour
One solution is to use the Global configuration Unicode Alias parameter in order to normalize all aliases.
Otherwise, indeed, it is the xx-XX.localise.php transliterate method of the current language which is used.
Related issues:
A user could be in this situation: a new content language is created before the related language pack is created/installed. In this case, there is no xx-XX.localise.php with its specific transliteration.
Also, before saving an item (article or menu item), the language the item is assigned to is not known. Therefore the alias would be automatically created without knowing the custom transliteration to apply from that language.