Opened 17 years ago
Last modified 14 years ago
#1172 confirmed Bug
FCKConfig.AutoDetectLanguage issue
| Reported by: | Aleksey Onopriyenko | Owned by: | |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | General | Version: | |
| Keywords: | Cc: |
Description
I believe the language of FCKeditor user interface has to be identical to the language of the page that contains an FCKeditor instance.
But if one set FCKConfig.AutoDetectLanguage = true ; the result will depend on the browser that a user use to browse Web.
In IE the FCKeditor language is identical to system locale settings. In Firefox it equals the value of general.useragent.locale property (see about:config). In Safari it is always English (at least on Windows).
Btw, there is no way to know the language of the current page.
So is it really useful option?
Change History (8)
comment:1 Changed 17 years ago by
comment:2 Changed 17 years ago by
Any internet cafe in Ukraine uses Russian version of Widows XP on their computers. So if you visit my country and browse internet in internet cafe you will not have any chance to see non-Russian interface of FCKeditor if a webmaster use FCKConfig.AutoDetectLanguage = true ; even if the page content is written in your native language. I think it is an undesirable result.
comment:3 Changed 17 years ago by
Interesting, but if it is removed then everyone that installs the editor will have to setup his language, and now it works automatically.
And if you provide the editor for a site that can be used in several languages it also works fine, but if it is removed then it will appear only in one language.
And we know that people is lazy, don't read the manuals and upgrade instructions and have too much trouble just changing the server connector from asp to php, I don't want to think about all the bug reports and forum posts because now the interface only appears in English but the previous version worked fine.
comment:4 Changed 17 years ago by
| Milestone: | → FCKeditor 3.0 |
|---|
I also agree that our current features already give the flexibility needed for it. Good web sites have good developers, which will certainly use the AutoDetectLanguage setting properly.
But, we can always make things better. We could certainly propose a new configuration option that instructs the editor to first try to get the language from the containing page, failing to the current browser language detection if nothing in the page can be found. To remember that the lang attribute is not exclusive to the <html> element.
comment:5 Changed 17 years ago by
comment:6 Changed 16 years ago by
| Keywords: | Confirmed added |
|---|
comment:7 Changed 15 years ago by
| Milestone: | CKEditor 3.0 → CKEditor 3.x |
|---|
I don't see any problem with that option.
By detecting and using automatically the user's language we know that the interface will be shown in a language that the user can understand (or he wouldn't be using that browser), and it is probably the one that he uses the most.
The language of the page would be available only if the root element had a lang attribute, but most of the pages don't include that, and even if I am using a foreign site, I can use its interface better if it is translated to my mother language.
Let's see the other way around: the option is removed. Then when the user tries to use FCKeditor he'll have everything in english unless the one that implemented FCKeditor in that site added that <html lang="ru"> or changed the fckconfig.js to set the language for the editor. But then everyone accesing that site will have the editor in that language, and even if the page is mostly in another language I might want to write something in a place were english is allowed, but if I get a russian interface it will be much harder.
In the end: I don't see any advantage to remove this option.