There aren't that many strings in egui right now that I can think of. There are a few tooltips when you hover e.g. a slider or a dragvalue. Is it these few strings you would like localized? I guess I can add them to some Options struct somewhere.

I'm glad for your reply.
I had searched the whole by using regex ".*?"[\),].
I think this bellow can be localize.

egui\src\widgets\slider.rs

• "{}\nClick to enter a value."

egui\src\widgets\mod.rs

• .on_hover_text("Extrusion")
• .on_hover_text("Width")
• if ui.add(Button::new("Reset").enabled(*value != def)).clicked

egui\src\widgets\drag_value.rs

• "{}{}{}\nDrag to edit or click to enter a value."

egui\src\widgets\color_picker.rs

• on_hover_text("Click to edit color")
• ui.label("Value / Saturation")
• ui.label("Value");
• ui.label("Saturation")
• ui.label("Hue")
• ui.label("Selected color")
• ui.label("Alpha")
• ui.label("Selected color")
• ui.radio_value(&mut additive, false, "Normal")
• ui.radio_value(&mut additive, true, "Additive")
• ui.label("Blending:")
• on_hover_text("Click to copy")
• "RGBA (premultiplied): rgba({}, {}, {}, {})"

What would you think about integrating one of the existing i18n crates into this project?

If you think this is a good idea, which one? The two leading contenders seem to be fluent-rs and gettext-rs.

I am very new to Rust and have never contributed to an open source project; but, this seems like an issue that I might be able to successfully tackle with some patience and guidance from this community.

Just my opinion, but both options do not feel like a great fit for egui. Both are overkill for supporting translations of the entire corpus of English text provided in #136 (comment) I can't be sure that this is a complete list, but even if it's a majority of text that appears in the UI that's worth pointing out.

• fluent is a heavy dependency, the full source tree weighs between 1.2 and 1.8 MB (depending on features enabled) according to https://lib.rs/crates/fluent
• gettext is LGPL (which may be itself an unreasonable constraint; depends on the needs of egui and its community) and requires a C compiler toolchain. Its source tree is 2.5 MB.

Given example strings in the earlier comment, this is probably a case where egui would rather do its own self-contained i18n. it may not support the majority of languages with this approach (especially RTL) but many of those languages have other problems with font rendering that need to be addressed separately. See #56

Once again, this is just my two cents. I'm merely a collaborator, and other people may have dissenting opinions!

@parasyte,

Thank you for your quick and considered response.

I actually think the LGPL is an unreasonable constraint which should almost certainly disqualify gettext from further consideration. (I had not looked past the MIT licensing of the gettext-rs crate; otherwise, I would not even have mentioned it.)

In fact, integrating any full fledged i18n crate may indeed be overkill. But, I do think it is reasonable to have an eye toward users of egui being able to easily integrate whatever i18n solution they use to replace egui's default labeling, pop-up messaging, etc. (I have been yelled at many times by my Brazilian user base when anything was displayed in English rather than Portuguese.)

Obviously, I have not spent the time needed to thoroughly think this through enough to offer any specific solutions.

If this work does indeed move forward, should the examples and template also be updated with some kind of i18n solution to make them more broadly accessible as well?

I want to keep this as simple as possible. egui is all about keeping dependencies to a minimum, and localizing user strings is out of scope for egui.

The few strings in egui that needs localization should just be moved to a struct, e.g.:

pub struct Localization {
    pub slider_tooltip: &'static str,
    pub drag_value_tooltip: &'static str,
    …
}

This could be accessed with e.g. ctx.localization() and set by users with something like ctx.set_localization(Localization::french());.

@emilk,

Understood. This makes sense.

I am happy to take a shot at this as long as there is no urgency.

I am very new to not only egui but also Rust; so, it will undoubtedly take me much longer than might be expected.

Please, feel free! I’m in no hurry :)

I will start on the code but need help with the actual translation of the strings mentioned in this issue, especially the ones from color_picker.rs. Please also indicate which language code (such as pt vs. pt-BR for Portuguese) is correct for each translation.

I can rely on Google Translate during development but will not create a PR without human translation/review.

Thank you.

I think we can start with just English and then people can help out with contributions in their own native tongue.

Hi, I am quite new to programming, Rust and open source contribution.

But I would like to take a shot at handling this issue at least for practice even if it's not merged.

I've completed a somewhat working localization based on xue-blood's comment and your suggestion and also integrated a language toggler into the demo for two languages (the default English and my native language Bahasa Malaysia).

Should I put up a draft PR so I can get feedback on my work?

Sure, a draft PR sounds good!

@flawphobic,

Excellent!

I had not forgotten about this but decided that I needed a bit more Rust and egui experience before diving into this. It looks like you are off to a great start. Thanks for picking up my slack.

Do you think about introducing a special type for localizable text? It will be great if compiler can forbid you from using hardcoded strings in the user interface by requiring a special type that can be only constructed using localization engine. That type should forbid concatenations (because you should never concatenate localizable strings as order of words is different in different languages). All text that you would write in sources actually would be a translation key. Strictly following such systems from a very low level should guarantee that we will never see unlocalizable text

I think we should instead limit the amount of text in egui. Most tooltips and the like have already been removed.