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

Localization team discussion issue #178

Open
sebasmagri opened this Issue Jul 12, 2017 · 24 comments

Comments

Projects
None yet
@sebasmagri

sebasmagri commented Jul 12, 2017

During RustDay in Mexico City, erickt, brson and I discussed about the benefits of having a dedicated localization team in the project.

The goals of such a team would include:

  • Orchestrate Rust content i18n
    • Documentation (partnering with -docs)
    • Videos (Amara)
    • Blog posts / Websites
  • Coordinate efforts to bring/improve i18n/l10n tooling into the ecosystem
  • Evaluate feasibility and implement i18n/l10n into the core tools
    • Compiler error messages (LANG/LC_* compliant on *nix?)

What else should we consider? What examples from other communities and open source projects can we use?

@GuillaumeGomez

This comment has been minimized.

Show comment
Hide comment
@GuillaumeGomez

GuillaumeGomez Jul 17, 2017

A long time ago, I opened a PR about adding localization for rustc itself. It was way too early but might be worth being discussed again?

GuillaumeGomez commented Jul 17, 2017

A long time ago, I opened a PR about adding localization for rustc itself. It was way too early but might be worth being discussed again?

@sebasmagri

This comment has been minimized.

Show comment
Hide comment
@sebasmagri

sebasmagri Jul 17, 2017

@GuillaumeGomez Sure thing... the idea of this issue is to start gathering feedback and ideas to define goals for the l10n team. rustc is definitely one of the targets.

sebasmagri commented Jul 17, 2017

@GuillaumeGomez Sure thing... the idea of this issue is to start gathering feedback and ideas to define goals for the l10n team. rustc is definitely one of the targets.

@skade

This comment has been minimized.

Show comment
Hide comment
@skade

skade Jul 20, 2017

Contributor

I would also try to get a list of currently running translation efforts and get in touch with the people doing them.

Contributor

skade commented Jul 20, 2017

I would also try to get a list of currently running translation efforts and get in touch with the people doing them.

@carols10cents

This comment has been minimized.

Show comment
Hide comment
@carols10cents
Contributor

carols10cents commented Jul 20, 2017

Translation efforts for the book are listed in this appendix and they each have an issue labeled Translations.

@carols10cents

This comment has been minimized.

Show comment
Hide comment
Contributor

carols10cents commented Jul 20, 2017

@spastorino

This comment has been minimized.

Show comment
Hide comment
@spastorino

spastorino Jul 25, 2017

I was talking with @sebasmagri and I think I'd focus on educational resources and the tooling ecosystem part for now.

spastorino commented Jul 25, 2017

I was talking with @sebasmagri and I think I'd focus on educational resources and the tooling ecosystem part for now.

@dvigneshwer

This comment has been minimized.

Show comment
Hide comment
@dvigneshwer

dvigneshwer Jul 25, 2017

We should also consider reaching out to the existing experienced Mozilla l10n community members for help, contributions, and guidance. They use a lot of cool tools like transifex etc.

dvigneshwer commented Jul 25, 2017

We should also consider reaching out to the existing experienced Mozilla l10n community members for help, contributions, and guidance. They use a lot of cool tools like transifex etc.

@sebasmagri

This comment has been minimized.

Show comment
Hide comment
@sebasmagri

sebasmagri Jul 29, 2017

Thanks for the suggestion @vigneshwerd. We're definitely willing to get in touch with them for this initiative.

I would also like to gather some feedback from the Chinese community. cc @KiChjang @tennix, @wayslog, @3442853561, @zonyitoo

sebasmagri commented Jul 29, 2017

Thanks for the suggestion @vigneshwerd. We're definitely willing to get in touch with them for this initiative.

I would also like to gather some feedback from the Chinese community. cc @KiChjang @tennix, @wayslog, @3442853561, @zonyitoo

@KiChjang

This comment has been minimized.

Show comment
Hide comment
@KiChjang

KiChjang commented Jul 29, 2017

Also cc @KaiserY.

@KiChjang

This comment has been minimized.

Show comment
Hide comment
@KiChjang

KiChjang Jul 29, 2017

I believe the most up-to-date Chinese translation efforts are still in https://github.com/ctjhoa/rust-learning/blob/master/zh_CN.md. In particular, I think RustPrimer is being used by quite a lot of people in the Chinese community to learn Rust.

@KaiserY has just told me that they've done translation of the Rust book 2nd edition up to chapter 19. More details in his repo: https://github.com/KaiserY/trpl-zh-cn.

KiChjang commented Jul 29, 2017

I believe the most up-to-date Chinese translation efforts are still in https://github.com/ctjhoa/rust-learning/blob/master/zh_CN.md. In particular, I think RustPrimer is being used by quite a lot of people in the Chinese community to learn Rust.

@KaiserY has just told me that they've done translation of the Rust book 2nd edition up to chapter 19. More details in his repo: https://github.com/KaiserY/trpl-zh-cn.

@skade

This comment has been minimized.

Show comment
Hide comment
@skade

skade Jul 29, 2017

Contributor

@sebasmagri Can #124 and #125 be folded into this?

Contributor

skade commented Jul 29, 2017

@sebasmagri Can #124 and #125 be folded into this?

@sebasmagri

This comment has been minimized.

Show comment
Hide comment
@sebasmagri

sebasmagri Jul 29, 2017

@skade yep, I think those issues should be part of this. Lets fold it and then we can reopen issues with the requirements well defined in the localisation repo.

sebasmagri commented Jul 29, 2017

@skade yep, I think those issues should be part of this. Lets fold it and then we can reopen issues with the requirements well defined in the localisation repo.

@ariasuni

This comment has been minimized.

Show comment
Hide comment
@ariasuni

ariasuni Jul 29, 2017

Two issues where created a long time ago concerning localization crates: rust-lang/rfcs#822 and rust-lang/rust#14495. I would definitely want to contribute to discussion and code about this.

ariasuni commented Jul 29, 2017

Two issues where created a long time ago concerning localization crates: rust-lang/rfcs#822 and rust-lang/rust#14495. I would definitely want to contribute to discussion and code about this.

@sebasmagri

This comment has been minimized.

Show comment
Hide comment
@sebasmagri

sebasmagri Jul 30, 2017

cc @hngnaig for Vietnamese efforts. 👍

sebasmagri commented Jul 30, 2017

cc @hngnaig for Vietnamese efforts. 👍

@3442853561

This comment has been minimized.

Show comment
Hide comment
@3442853561

3442853561 Aug 3, 2017

I thought it would be nice to have a multi-lingual document annotation, although I didn't figure out how to do this

3442853561 commented Aug 3, 2017

I thought it would be nice to have a multi-lingual document annotation, although I didn't figure out how to do this

@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Dec 23, 2017

Contributor

One thing worth mentioning is that stuff like i18n of the compiler is a really tricky business if we want to do it right. Languages are hard, and building systems that support all of them (e.g. supporting the 6 different kinds of pluralization Arabic has) is a tricky business. If we find a good i18n library in Rust we can use that, but it's likely we'll have to build our own.

We probably should focus on organizing community to translate docs/etc (and organizing these translated docs themselves, we already have a couple), and once this is bootstrapped we can look into i18ning the compiler.

(It seems like the above proposal is very much in line with this, just wanted to reiterate why we should do it that way)

Contributor

Manishearth commented Dec 23, 2017

One thing worth mentioning is that stuff like i18n of the compiler is a really tricky business if we want to do it right. Languages are hard, and building systems that support all of them (e.g. supporting the 6 different kinds of pluralization Arabic has) is a tricky business. If we find a good i18n library in Rust we can use that, but it's likely we'll have to build our own.

We probably should focus on organizing community to translate docs/etc (and organizing these translated docs themselves, we already have a couple), and once this is bootstrapped we can look into i18ning the compiler.

(It seems like the above proposal is very much in line with this, just wanted to reiterate why we should do it that way)

@skade

This comment has been minimized.

Show comment
Hide comment
@skade

skade Dec 23, 2017

Contributor
Contributor

skade commented Dec 23, 2017

@KiChjang

This comment has been minimized.

Show comment
Hide comment
@KiChjang

KiChjang Dec 23, 2017

Indeed, I do see that there has been several discussions about i18n, but we've never moved beyond words, and I think the reason is pretty much because nobody knows how to kick start an i18n project for the Rust compiler. Coupled with the fact that such a change requires an RFC, it makes the task more daunting.

KiChjang commented Dec 23, 2017

Indeed, I do see that there has been several discussions about i18n, but we've never moved beyond words, and I think the reason is pretty much because nobody knows how to kick start an i18n project for the Rust compiler. Coupled with the fact that such a change requires an RFC, it makes the task more daunting.

@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Dec 23, 2017

Contributor
Contributor

Manishearth commented Dec 23, 2017

@psychoslave

This comment has been minimized.

Show comment
Hide comment
@psychoslave

psychoslave Dec 23, 2017

@sebasmagri invited me to join this discussion following a conversation on the internationalization of Rust itself.

In a nutshell, the proposal is to allow localized source code happen, identifiers and keywords included. So English, or something like "EN-Rust", might still be used as the preferred default locale, while allowing others locales to operate with the level of integration, especially for debugging/profiling sessions. Plus some tools might help to make quick translexicalisation from one locale to an other, in case of migration, or willing to post some snippets when requiring help from an other linguistic community.

psychoslave commented Dec 23, 2017

@sebasmagri invited me to join this discussion following a conversation on the internationalization of Rust itself.

In a nutshell, the proposal is to allow localized source code happen, identifiers and keywords included. So English, or something like "EN-Rust", might still be used as the preferred default locale, while allowing others locales to operate with the level of integration, especially for debugging/profiling sessions. Plus some tools might help to make quick translexicalisation from one locale to an other, in case of migration, or willing to post some snippets when requiring help from an other linguistic community.

@sebasmagri

This comment has been minimized.

Show comment
Hide comment
@sebasmagri

sebasmagri Dec 23, 2017

Hi! It's awesome to finally get more feedback here. So I'd like to do a quick review for those who are joining the conversation.

The rustc i18n of error messages is something that has been discussed many times. However, a final solution to this has not been identified. There is no centralized evidence of the different opinions on this front, though. It's all scattered in several issues and comments in RFCs and PRs.

OTOH, there are a bunch of initiatives in the ecosystem to provide good quality and standards based crates for ICU and l10n/i18n. However, there is little communication between them and I think they could take advantage of having a common ground. This common ground will probably be provided by the compiler since it's gonna need it anyway for its internal l10n/i18n support, but it doesn't need to support all the features that fully pledged libraries support. I like to think of this working in a similar way to the log crate; providing base traits and a reference implementation used in rustc and std.

The other part of this is resources and documentation, namely The Rust Programming Language book, which means improving mdBook's support for i18n, and rustdoc support for multilingual docs. Efforts to translate TRPL, for example, has been tracked by @carols10cents, yet it needs more coordination if we want to establish having the official docs translation as a goal.

So, I'd like to invite you all to provide feedback to an in-progress preRFC for a Localisation Team, which considers all the different fronts n which we'd need to work in l10n/i18n in the broader Rust project.

Thanks!

sebasmagri commented Dec 23, 2017

Hi! It's awesome to finally get more feedback here. So I'd like to do a quick review for those who are joining the conversation.

The rustc i18n of error messages is something that has been discussed many times. However, a final solution to this has not been identified. There is no centralized evidence of the different opinions on this front, though. It's all scattered in several issues and comments in RFCs and PRs.

OTOH, there are a bunch of initiatives in the ecosystem to provide good quality and standards based crates for ICU and l10n/i18n. However, there is little communication between them and I think they could take advantage of having a common ground. This common ground will probably be provided by the compiler since it's gonna need it anyway for its internal l10n/i18n support, but it doesn't need to support all the features that fully pledged libraries support. I like to think of this working in a similar way to the log crate; providing base traits and a reference implementation used in rustc and std.

The other part of this is resources and documentation, namely The Rust Programming Language book, which means improving mdBook's support for i18n, and rustdoc support for multilingual docs. Efforts to translate TRPL, for example, has been tracked by @carols10cents, yet it needs more coordination if we want to establish having the official docs translation as a goal.

So, I'd like to invite you all to provide feedback to an in-progress preRFC for a Localisation Team, which considers all the different fronts n which we'd need to work in l10n/i18n in the broader Rust project.

Thanks!

@psychoslave

This comment has been minimized.

Show comment
Hide comment
@psychoslave

psychoslave Dec 23, 2017

@sebasmagri I'm not sure my suggestion regarding enabling internationalisation and localisation of Rust itself would have its place in this preRFC. Would you be kind enough to confirn or infirm that I should come add this topic in this conversation?

Apart from that, speaking about communication and common ground, I started a research project on Internationalisation of Programming Languages. I will add a Rust section in the part about state of the art. Everyone is welcome to join this wiki project to enrich it on Rust on any other programming language, as long as it is to talk about the topic treated in the research of course.

Kind regards

psychoslave commented Dec 23, 2017

@sebasmagri I'm not sure my suggestion regarding enabling internationalisation and localisation of Rust itself would have its place in this preRFC. Would you be kind enough to confirn or infirm that I should come add this topic in this conversation?

Apart from that, speaking about communication and common ground, I started a research project on Internationalisation of Programming Languages. I will add a Rust section in the part about state of the art. Everyone is welcome to join this wiki project to enrich it on Rust on any other programming language, as long as it is to talk about the topic treated in the research of course.

Kind regards

@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Dec 23, 2017

Contributor
Contributor

Manishearth commented Dec 23, 2017

@psychoslave

This comment has been minimized.

Show comment
Hide comment
@psychoslave

psychoslave Dec 23, 2017

OK, then it is a topic which does belong on any open issue, or that a new issue on this topic is welcome, just let me know. Otherwise I will stop to add further comment on this topic on this repository, and will only follow update on the discourse thread.

By the way, you might be interested with
GopherCon 2017: Aditya Mukerjee - Translating Go to Other (Human) Languages, and Back Again - YouTube

I also discovered that Perl 6 slangs open large flexibility regarding what is parsable to feed the underlying interpreter, all through native facilities as far as I can judge from reading the doc.

psychoslave commented Dec 23, 2017

OK, then it is a topic which does belong on any open issue, or that a new issue on this topic is welcome, just let me know. Otherwise I will stop to add further comment on this topic on this repository, and will only follow update on the discourse thread.

By the way, you might be interested with
GopherCon 2017: Aditya Mukerjee - Translating Go to Other (Human) Languages, and Back Again - YouTube

I also discovered that Perl 6 slangs open large flexibility regarding what is parsable to feed the underlying interpreter, all through native facilities as far as I can judge from reading the doc.

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