Using L10N in a library and a binary

[IzawGithub]

Hello, thanks for the library! It's working great for my need, the compile time check makes working with localization much more pleasant.

I've been using this project for a bit, and I have a binary crate that uses it.
It works fine like that, but I've been working on separating the logic from the binary to a library.

I want to use L10N for both the library, and the binary. This means that I need two different localization folder, but I haven't seen anything in the documentation about this. Is it supported? And if so, how?

Minimal reproducible example:

/// -- lib/l10n/en/lib.ftl --

Loc-lib = Localisation of the lib.

/// -------------------------

/// -- bin/l10n/en/bin.ftl --

Loc-bin = Localisation of the bin.

/// -------------------------

/// -- lib.rs --

l10n::init({});

message!("lib", "Loc-lib").translate(&langid!("en"));

// ------------

/// -- bin.rs --

use lib::L10N;

// Errors here, "bin" does not exist
message!("bin", "Loc-bin").translate(&langid!("en"));

// ------------

[MathieuTricoire]

Sorry for the late answer, I didn't find a solution to what you're asking for.

I tried using build scripts to pass env. var but they are passed to all targets, I would be surprised there is not a way to do that with cargo but I didn't find how for now.

I would try in the future to add an environment var like L10N_PATH that could be set like what it's done in the env_logger crate L10N_PATH=[target][=][path][,...] so we could do something like L10N_PATH=binary_target_name=l10n_bin,library_target_name=l10n_lib.
And maybe go a little bit further in situation where the binary and the library have the same name, specifying the target "type" as a prefix for disambiguation, that would give something like L10N_PATH=bin:target_name=l10n_bin,lib:target_name=l10n_lib

But right now your best shot is to do something like this:

l10n/
  en/
    bin/
      resource1.ftl ("Loc-bin = Message for the binary from the shared l10n.")
    lib/
      resource1.ftl ("Loc-lib = Message for the library from the shared l10n.")
  fr/
    bin/
      resource1.ftl ("Loc-bin = Message pour l'éxécutable depuis le dossier l10n partagé.")
    lib/
      resource1.ftl ("Loc-lib = Message pour la librairie depuis le dossier l10n partagé.")

main.rs

use test_l10n::lib_fn;

use l10n::unic_langid::langid;
use l10n::{message, L10nMessage};

l10n::init!();

fn main() {
    let fr = &langid!("fr");
    let en = &langid!("en");

    let message = message!("bin/resource1", "Loc-bin");

    println!("binary:");
    println!("- french: {}", message.translate(fr));
    println!("- english: {}", message.translate(en));

    println!();
    lib_fn();
}

lib.rs

use l10n::unic_langid::langid;
use l10n::{message, L10nMessage};

l10n::init!();

pub fn lib_fn() {
    let fr = &langid!("fr");
    let en = &langid!("en");

    let message = message!("lib/resource1", "Loc-lib");

    println!("library:");
    println!("- french: {}", message.translate(fr));
    println!("- english: {}", message.translate(en));
}

[IzawGithub]

Hello, thanks for the response!

This is also what I though about doing at first. This works fine for a monorepo or for stuff like xtask, but for completely different crate that don't share the repo it's a bit annoying.

Nonetheless this works so I'll close and mark as answered, thank you.

[MathieuTricoire]

I might have misunderstood your question. I assumed you were referring to using different localization directories within a single package that contains multiple crates (one library, one or more binaries), all under one Cargo.toml file, like this:

src/
    lib.rs
    main.rs
Cargo.toml

If you have distinct packages, this is possible, but it can lead to frustration if you don't fully understand how it works under the hood, and my documentation doesn't explain this correctly...
The default path to the localization directory is relative to the directory containing the Cargo.toml file.

This is how l10n::init!(); compiles to by default:

pub static L10N: ::l10n::once_cell::sync::Lazy<::l10n::L10n> = ::l10n::once_cell::sync::Lazy::new(||
{
    ::l10n::L10nBuilder::parse(
            "l10n",
            std::option::Option::Some(
                ::l10n::Locales::try_from([
                        ("fr", std::option::Option::None),
                        ("en", std::option::Option::None),
                    ])
                    .expect("unexpected error parsing a locale"),
            ),
        )
        .expect("error parsing translation files")
        .build()
        .expect("error building translator")
});

So you can see at line 4 that the path l10n is relative.

So your dependencies (library crates) should use a special config file l10n.toml to compiles with an absolute path to the localization directory, for example:

[l10n]
path = "$ROOT/custom_l10n"

Then l10n::init!(); in the library crate located in /var/my_package/external_library will compiles to this:

pub static L10N: ::l10n::once_cell::sync::Lazy<::l10n::L10n> = ::l10n::once_cell::sync::Lazy::new(||
{
    ::l10n::L10nBuilder::parse(
            "/var/my_package/external_library/custom_l10n",
            std::option::Option::Some(
                ::l10n::Locales::try_from([
                        ("en", std::option::Option::None),
                        ("fr", std::option::Option::None),
                    ])
                    .expect("unexpected error parsing a locale"),
            ),
        )
        .expect("error parsing translation files")
        .build()
        .expect("error building translator")
});

So it will work correctly during your development flow and when running, provided that the localization directories (whether relative or not) for your binary and dependencies are present and you run the binary from the right directory (or using cargo).

This means that if you compile your code on one machine and deploy it on another, you need to replicate the localization directories with the correct paths and launch your binary from the right directory. However, if you compile directly on the deployed machine, it should be fine.

I'm really not happy with all of this, and I plan to embed the translations directly into the crates for the next version. This way, you won't have to worry about these issues, especially when deploying.

Thank you for bringing up this issue. It allows me to explain some of the flaws of my crate. Unfortunately, I don't have time to work on it right now, but I hope to provide a new version in the coming months to address this.

I have created a repository to give you an example how it works without and with a workspace: https://github.com/MathieuTricoire/l10n-example-deps