Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Fluent in Zotero 7 #275

Closed
diegodlh opened this issue Jul 17, 2024 · 4 comments · Fixed by #278
Closed

Use Fluent in Zotero 7 #275

diegodlh opened this issue Jul 17, 2024 · 4 comments · Fixed by #278

Comments

@diegodlh
Copy link
Owner

diegodlh commented Jul 17, 2024

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: 542eee6

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 d3f0faa

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
Copy link
Collaborator

Dominic-DallOsto commented Jul 18, 2024

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
Copy link
Owner Author

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
Copy link
Collaborator

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
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants