Create individual language files

[ZeroDot1]

Is there an existing issue for this?

• I have searched the existing issues.

Describe the solution you'd like

At the moment it is not so good to translate Sniffnet. I recommend to create a separate language file for each language. Having the language information directly in the source code is not very smart. It brings the risk of unpredictable security problems due to faulty source code.

Is your feature request related to a problem?

No response

[ZeroDot1]

Sample:

[dependencies]
gettext-rs = "0.0"

msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
"Language: de\n"

msgid "Hello, world!"
msgstr "Hallo, Welt!"

msgid "Goodbye, world!"
msgstr "Auf Wiedersehen, Welt!"

msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
"Language: en\n"

msgid "Hello, world!"
msgstr "Hello, world!"

msgid "Goodbye, world!"
msgstr "Goodbye, world!"

use gettext::Catalog;
use std::fs::File;
use std::io::Read;
use std::path::Path;

fn load_catalog(lang: &str) -> Catalog {
    let path = format!("locales/{}/LC_MESSAGES/messages.mo", lang);
    let mut file = File::open(&path).expect("Failed to open catalog file");
    let mut buffer = Vec::new();
    file.read_to_end(&mut buffer).expect("Failed to read catalog file");
    Catalog::parse(&buffer).expect("Failed to parse catalog")
}

fn main() {
    // Lade die Kataloge für Deutsch und Englisch
    let catalog_de = load_catalog("de");
    let catalog_en = load_catalog("en");

    // Übersetzungen für Deutsch
    println!("Deutsch:");
    println!("{}", catalog_de.gettext("Hello, world!"));
    println!("{}", catalog_de.gettext("Goodbye, world!"));

    // Übersetzungen für Englisch
    println!("\nEnglisch:");
    println!("{}", catalog_en.gettext("Hello, world!"));
    println!("{}", catalog_en.gettext("Goodbye, world!"));
}

[GyulyVGC]

It seems like an over complication to me.

I appreciate your suggestion, but I prefer to keep things as they're.

[GyulyVGC]

Moreover getting text using a string key is going on the opposite direction as it's making the code less robust and type safe, going against a Rust principles.
Using match-based function is more idiomatic in this case.

[GyulyVGC]

Without considering that some of the translations are not static but are formatted taking into account input parameters, so we need them to be in code.