Use Fluent in Zotero 7

[diegodlh]

Zotero 7 uses Mozilla's Fluent for localization: https://www.zotero.org/support/dev/zotero_7_for_developers#localization

@Dominic-DallOsto Dominic has already done some work to support this: https://github.com/diegodlh/zotero-cita/commit/542eee6fc89949f4c775010c29a5daa2b9c12d56

I'm still going through the changes, but from what I've seen so far (so I can pick up from here later):

Fluent uses .ftl files instead of .properties

• wikicite.properties files have been renamed as wikicite.ftl
• For English only (en-US) a addon.ftl file has been created with changes needed (or supported) by Fluent:
  • Fluent needs named parameters (e.g., {supplierName} instead of simply %s or %1$s
  • Plurals and nested (?) keys
• Points (.) separating key "levels" have been replaced by dashes (-).

Regarding named parameters, I'm not sure this is supported by Translatewiki; I will ask. If not, I guess we can use numbered parameters (we already did in some cases: e.g., %2$s), either directly from Translatewiki ({1}, {2}, etc?) or by converting them (i.e., %1$d -> {1}) upon build.

Regarding plurals, I understand Translatewiki does support them, but I would prefer leaving this for a later time.

Regarding points and dashes, I haven't checked yet if dashes are needed by Fluent. In any case, I would try to find a way to continue differentiating between message "level" separation, and separation of words within a level. For example, in wikicite.citation.auto-link.failure.title it should be clear that "levels" are nested as follows:

• wikicite
  • citation
  • auto-link - note that the dash here separates words within a "level"
    • failure
    • title

getString function redefinition

Our Wikicite.getString function has been moved to src/utils/locale.ts (neat!) and redefined to use Firefox's formatMessagesSync (haven't checked the implementation in detail).

---

Also, from the little initial experience I have had so far, the following are pending:

Replace Services.locale.getRequestedLocale calls

Our call to Services.locale.getRequestedLocale is failing. We need to use an alternative way to get the current locale. Fixed in d3f0faa1cd5579e1a581fca3b1344620503bb9a5

Remove react-intl dependency

This is probably not needed anymore, along with anything else we may have been using to support internationalization before Zotero 7.

[Dominic-DallOsto]

Yeah, I think dots can/should only be used to specify sub properties of a message as explained here. It was giving me an .ftl syntax error so I just converted them all to dashes. But maybe underscores actually makes more sense like better bibtex does.

If there are some limitations imposed by translatewiki then we can work out how to deal with them. Like you saw having named instead of numbers parameters is a big change, but (if supported) I guess makes it easier for translators to work with...

[diegodlh]

I just posted a question to the Translatewiki admins here: https://translatewiki.net/w/i.php?title=Translating_talk%3ACita#Major_message_key_and_variable_renaming

I would prioritize making Translatewiki translations work with the new version of Cita and then we can gradually add improvements such as named variables (if supported), plurals, etc.

[Dominic-DallOsto]

Worst case if changing things over on translatewiki are too hard / not possible we could have an extra step that automatically converts the existing .properties files into .ftl

[Dominic-DallOsto]

Basic functionality implemented by #278, with some future issues also outlined there.