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

i10n #1292

Closed
wants to merge 6 commits into from
Closed

i10n #1292

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
92 changes: 92 additions & 0 deletions text/000-i18n.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,92 @@
Feature Name: i18n
- Start Date: 2015-09-24
- RFC PR: (leave this empty)
- Rust Issue: (leave this empty)

# Summary

This RFC proposes to add an internationalization framework to the rust compiler.

#Motivations

With the growth of the number of users of Rust, localizing the compiler output would be a big plus.

#Proposal

We make every user-facing string in the compiler into a key-value pair.

For example, the following string output by the compiler:

```text
test.rs:2:4: 2:6 error: expected one of `.`, `;`, `}`, or an operator, found `::`
```

would be created via:

```Rust
format_lang!("parser.expected_operator", expected, found)
```

We would store all translations in localization files which would contain key value pairs. For example:

```
// in english file
parser.expected_operator = "expected one of {} or an operator, found {}"

// in french file
parser.expected_operator = "un opérateur ou l'un des symboles suivants était attendu: {}, obtenu: {}"
```

If no translation is found, the english localization is used.

To use a specific language, one can run rustc as follows:

```Shell
> rustc --lang fr <other arguments>
```

##Long diagnostics

For error codes / long diagnostics, we keep a different file format for convenience and instead of statically baking in the string, we do a file lookup. The only difference will be that instead of calling:

```Rust
span_err!(E0123, format!("error description {}", some_substitution));
```
we will write:

```Rust
span_err!(diagnostics.E0123, some_substitution);
```

There will be two diagnostics keys for this, the short and long diagnostic.

```
diagnostics.E0123.short = "error description {}"
diagnostics.E0123.long = """foo bar baz \
quux \
... \
"""
```

##Storage of localizations

The localization files should be stored in a folder called i10n, which is part of the rust installation folder. By default, the english files will be there, but if you put the french files there, the option `--lang fr` will work. The folder will look like this:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there any plans on a file format? Or is this just an implementation detail at this point?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean by file format ? Is it about how the localization file is written or how it is compressed ? On the first one, it has been explained a bit upper, for the second one, not really.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a text file with keyvalue pairs as rust strings.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it about how the localization file is written

Yes, I thought the text format shown above was just as an example.

Just a text file with keyvalue pairs as rust strings.

With lots of keys and sub-keys you might want to consider an indexed structure, for example. This could also be added in the future, though, if there was a clear way of versioning these files. (Also, I'm sure there are a lot of existing formats for these kind of thing.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With lots of keys and sub-keys you might want to consider an indexed structure

I don't think we'll need that.

This particular format is basically a copy of Firefox's .properties files for JS l10n (they use DTDs for HTML/XUL l10n).

Firefox has tons of these, but each JS file only loads the necessary ones for performance. They don't have nested keys though.

We don't need to do what Firefox does since these are for errors and warnings -- pretty cheap to do file I/O to fetch this information.


```
i10n
|
|---en
|
|---diagnostics
|---parser
```


##Language pack

The localization files will be exported as compressed files to allow user to download and handle them easily. To install a new package, the following command will be run:

```Shell
rustc --install-lang fr # downloads an official language pack from the server
rustc --install-lang fr=pack.zip # a custom pack can be installed this way
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I like the idea of adding a subcommand that downloads and extracts files to rustc. I'd rather see a separate utility to install these language packs (could also be part of multirust).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or a part of install.sh/rustup.sh (or whatever it's called these days).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see the issue to add such a thing to rust. Since localization will be handled by compiler directly, why not the language packs too ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issue is that rustc will be talking over the network, we don't want that.

So the compiler will have support for language packs, just not for downloading/installing them.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not talking over the network ? I don't really see the issue here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh my bad. Didn't think of that. Thanks for the info !

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rustc also won’t be able to save these packs most of the time anyways since you need administrative privileges for that in current versions of all major systems.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just like rust_install.sh. I don't think this is a real issue here. They can just launch the command with sudo if needed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You don’t simply launch compilers as root. If a compiler needs administrative privileges, then something went wrong somewhere.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a side thing, so I don't find it abnormal.

```