Skip to content

Internationalization with Project Fluent #14

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

Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
81 changes: 81 additions & 0 deletions rfcs/fluent-internationalization.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,81 @@
# Feature Name: `fluent-internationalization`

## Summary

Internationalization is the practice of adapting your app's user interface to support multiple languages.
This RFC proposes how we can create a first-class integration with the [`fluent-rs`](https://github.com/projectfluent/fluent-rs) crate.

## Motivation

Internationalization is an important feature for serious games and apps, allowing them to expand their audience beyond a single language.
The technical challenges are well-understood, and not insurmountable, but retrofitting existing designs to accommodate them is notoriously painful.

Even for unilingual games, a high-quality internationalization language provides excellent support for dynamically changing text:
interpolating names, adapting nearby words to the correct plurality and gender, date and time formatting and so on.
This is very useful for building polished UIs in games, where the details of what a widget or dialog box should display often vary dramatically based on player actions.

## Guide-level explanation

TODO: Write.

Language Resource.

Labels for text and audio.

Assets should use real text if possible.

## Reference-level explanation

TODO: Write.

## Drawbacks

1. The data model for unilingual text is necessarily more complex.
2. Our dependency tree will grow.
3. We're forced to confront challenges around variable text length, left-to-right text, non-Latin glyphs etc. sooner.

## Rationale and alternatives

### Why does Bevy itself need internationalization?

1. By establishing a single standard, we can ensure that ecosystem crates (for e.g. dialog, widgets) all interoperate correctly.
2. Bevy should have text-enabled widgets in `bevy_ui`. If we don't support localization on those, they will quickly be obsoleted by third-party equivalents.
3. Bevy itself is responsible for solving many of the ancillary problems induced by variable text contents, such as automatically rescaling UIs.
4. By enabling internationalization by default, games can seamlessly mature, rather than having to rip out all related prototyping work.
5. Existing internationalization solutions in other game engines are typically bolted-on and second-class. Excellent integration with a high-quality internationalization solution offers a serious competitive advantage for multilingual indie developers and serious commercial game developers considering Bevy.

### Why Fluent?

TODO: Write.

## Prior art

An existing Bevy integration with `fluent-rs`, [`bevy_fluent`](https://crates.io/crates/bevy_fluent) shows that basic integration is quite simple.

[Project Fluent](https://projectfluent.org/) has a great overview explaining the limitations of simpler approaches to localization.

### Internationalization in other game engines

#### Unity

TODO: Research.

https://medium.com/i18n-and-l10n-resources-for-developers/localizing-unity-games-with-the-official-localization-package-5e2f59779d45

#### Unreal

TODO: Research.

https://docs.unrealengine.com/en-US/ProductionPipelines/Localization/Overview/index.html

#### Godot

TODO: Research.

https://docs.godotengine.org/en/stable/tutorials/i18n/internationalizing_games.html

## Unresolved questions

1. How do we ensure that the "simple case" of code-only static text in a single language is still easy?
2. How do we ensure that translators have appropriate access to context?
3. How do we generalize over different asset types?