Replies: 1 comment 2 replies
-
Thanks to create Discussion about this, Agree with priorize now vs after, now impact its better vs 1 month, or 1 year. Im investigate Project Fluent, and i18n have pluralization feature, other features I think are not "better" to translators, In my experience, translators want .PO file or .json or platform to translate texts directly and not think in pluralization, genders etc And in this app, I think only require pluralization, not others, But for me fluent are a valid solution too. Agree to reconsider the early i18n support. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This is a following of #7433 (related to ticket #7409).
Hello Zed team,
While I do understand your point in the merge request's reply that changes should first be discussed, I would like to advocate for implementing an internationalisation system within the editor early in the development process since I believe it avoids scale issues that happen when implemented later, e.g. the need to update 100 strings v. update 100000k strings.
My main objective with the creation of this discussion is to spread the idea of i18n within the team, however, I can also recommend a few ideas to implement such as feature.
Indeed, unlike the
rust_i18n
recommended by Carlos Lopez (@foxkdev) in the ticket, I do encourage the adoption of Mozilla's Project Fluent, which is the result of various researches in the domain of translating software.In hope the team reconsider the choice against early i18n support,
Nicolas Paul
Beta Was this translation helpful? Give feedback.
All reactions