intl.accept_language setting no longer works

The intl.accept_language setting in config editor no longer works in latest Zotero version.

The default value is "en-US, en". Edit this setting, save it and restart Zotero, you will see its value is restored to its original value.

This setting is important to me, because I want my zotero's UI language to be English (and my system's locale is en-US) while I do use some other language in my zotero notes. This setting is essential for Zotero to choose the right font to display my notes.

My note is in Chinese, encoded in UTF-8. UTF-8 can encode any language.
Zotero first try to render it with English fonts, then fallback to Japanese fonts to render some Chinese characters, then fallback to Chinese fonts to render some characters not included in Japanese. In the end, I get a combination of three fonts!
Set this option to "zh-CN, zh, en-US, en" or "en-US, en, zh-CN, zh" can remove the Japanese font and give it a nice rendering.

Similarly, if a user have some note in German but his English font doesn't have all German characters (most fonts have, but if the user choose a rare font, then he would have the problem), he would see ugly fonts combination too.

I used to use this option and it worked well. Recently with Zotero's update, this option no longer works.
  • Yes, intl.accept_languages is set to a value determined by the current locale, so that webpage snapshots are in the expected language. That's been the case since July 2017, so this wouldn't be a recent change.

    I'm not sure why that setting has any effect on the display of Zotero notes, though. That setting, which we inherit from Firefox, changes the value of the Accept-Language header sent to websites. It's not meant to have any effect on the user interface, and in Zotero it's not really intended to be a public setting. What made you change this in the first place? Did you find documentation on Firefox's font fallback behavior that indicated that this preference is involved?
  • Yes. I found discussion about Firefox fonts fallback behavior many years ago and always used this setting in both Firefox and Zotero to keep Chinese properly rendered.

    Chinese has the problem that there are lots of locale about Chinese. zh-CN, zh-HK, zh-TW, jp, ko, etc. Surely a Japanese font won't have all characters a font designed for zh-CN would have. There are even difference between zh-CN and zh-HK.

    I have to apologize that I didn't update my Zotero frequently so I don't really have an idea about what is the exact version changed Zotero's behavior.

    This setting doesn't have effect on Zotero's menu (that is set to system locale) It affect search box, entries titles, notes titles and notes contents. In summary, any place that user can set the text content to non-English.

    In Firefox 56 and after 56, this setting can ensure the proper font fallback when Firefox don't know the language of the text, though it might not be the best choice, but it works.

    For my understanding, Firefox Gecko first try to figure out the encoding of the text and see if there is any language indicated in webpage or HTTP header. If the text is encoded in cp936, then it must be zh-CN thus use default font for Chinese to render it.
    However, for UTF-8 content, there is no easy way to guess the language. And who say a English webpage can't have some Chinese characters? So it use the default font to render and fallback to other fonts if the default font doesn't have that character.
    It seems that the priority is current locale -> jp -> zh-CN -> zh-HK -> zh-TW. Sounds like an alphabetic order.

    Maybe one option is to use a Unicode font like Arial Unicode MS for Zotero. But that is also a hidden option in config editor!
  • I find Mozilla's official document for this.

    Though this explains how to set this on Firefox's option page, but it directly changes the intl.accept_language option under hood.
  • Actually my setting is a little more complicated that I described.
    My system is Windows 10 English version and my system locale is zh-CN. I have all system interfaces in English, only set locale to Chinese to be compatible with some CP936 text and programs.
    I have zotero intl.locale.matchOS set as false and force zotero to use en-US for user interface and preferred citing style.
    Thus zotero isn't setting intl.accept_language to my system locale, but set it as the same as zotero user interface locale.
  • edited February 18, 2019
    Thus zotero isn't setting intl.accept_language to my system locale, but set it as the same as zotero user interface locale.
    Yes, I meant it's set based on Zotero's locale setting.
    I have zotero intl.locale.matchOS set as false and force zotero to use en-US for user interface and preferred citing style.
    It's no longer necessary to touch these, by the way — those are just set by the Language setting in the Advanced pane of the preferences. And the bibliography locale is configurable in the places where you generate citations and bibliographies.
    That's not describing this behavior, though. That's still just about the Accept-Language header sent to websites. What you say about using it as a language hint for font fallback with UTF-8 content makes sense — I was just curious if you saw it documented somewhere. I imagine it's discussed in Bugzilla somewhere, but it doesn't matter. Without actually looking at the code, I'd guess that it's this section in the current Firefox codebase.

    In any case, I'm afraid we won't be able to change this behavior at the current time, and it will change completely when we switch to Electron (hopefully later this year). For now, if you want to use the English locale and intl.accept_languages has an unintended effect, you'll need to work around it somehow, by adjusting that preference after restarting Zotero, changing the font used in Zotero, or building your own version of Zotero with the relevant line disabled.
  • Thank your for your kind response!
    I would be looking forward to see the new Zotero!

    One thing I like Zotero is that its unbeatable accessibility support. Because Firefox is the most accessibility friendly browser. Zotero inherit nearly every accessibility from Firefox including the support for screen reader, windows high contrast mode and so on.

    Unluckily, there are some Electron based applications lack of accessibility. To name some: Atom and VSCode don't work with screen reader at all. I heard it is the problem of Electron.

    I guess though I would be very excited to see the new face of zotero, without accessibility support, many people would stick to the old Firefox based zotero for years.

    I think the majority of users will welcome the new Electoron version with prettier look. My only hope is that the Firefox version can be maintained for some time, keep its sync function working and compatible with new version.

    For people with disabilities, changing tools is a big deal. Not to say that there is actually no replacement for Zotero at this time.
Sign In or Register to comment.