Feature Description
At the moment, the translation domain is hard-coded to the package name:
|
compiler_config.translation_domain = std::env::var("CARGO_PKG_NAME").ok(); |
This makes it inconvenient to share PO files across packages. It would be nice to be able override this, for example via a CompilerConfiguration method. Alternatively, it would also work if Slint accepted any file named *.po in the relevant directory, possibly failing if there is more than one. A more invasive change would be to get rid of domains (and the LC_MESSAGES directory) entirely and flatten the structure from lang/de/LC_MESSAGES/domain.po to lang/de.po, where the name of the PO file identifies the language, as suggested in #3715 (comment). I like this approach best, because it makes managing the PO files more convenient, in addition to achieving the main goal of allowing sharing between packages.
Such changes might also impact live-preview, as noted in #9942 (comment).
Not having to use the package name as the domain name would enable using one set of PO files for multiple, differently-named packages, significantly reducing duplication when developing multiple packages which share some of their messages.
Product Impact
No response
Feature Description
At the moment, the translation domain is hard-coded to the package name:
slint/api/rs/build/lib.rs
Line 588 in dccd890
This makes it inconvenient to share PO files across packages. It would be nice to be able override this, for example via a
CompilerConfigurationmethod. Alternatively, it would also work if Slint accepted any file named*.poin the relevant directory, possibly failing if there is more than one. A more invasive change would be to get rid of domains (and theLC_MESSAGESdirectory) entirely and flatten the structure fromlang/de/LC_MESSAGES/domain.potolang/de.po, where the name of the PO file identifies the language, as suggested in #3715 (comment). I like this approach best, because it makes managing the PO files more convenient, in addition to achieving the main goal of allowing sharing between packages.Such changes might also impact live-preview, as noted in #9942 (comment).
Not having to use the package name as the domain name would enable using one set of PO files for multiple, differently-named packages, significantly reducing duplication when developing multiple packages which share some of their messages.
Product Impact
No response