LV2 Manifest I18n

[jpcima]

Hi, I have noted that RDF format supports translation natively, and LV2 hosts support it, although not being widely used at all.

There is an example of LV2 with i18n. https://github.com/lucianodato/noise-repellent/blob/master/lv2ttl/nrepel.ttl

A question is: how would i18n be best implemented in the LV2 exporter? At best, translators work in translation catalog files which are separate from the sources files.

[falkTX]

Languages are always tricky to handle. VST also has a way to specify language btw, but it is limited to a hardcoded list of values.

i18n needs to be optional, and hopefully not introduce new dependencies. for the UI, we can simply have a new function that returns the current language code.

but for DSP side might be more tricky.. do we let DSP know the language and have it return different things based on the language?

does the plugin need a way to inform the supported languages to DPF?

maybe something like this for parameters:

struct TranslatedString {
  String lang; // a "code" like "en_US", "fr_FR", etc
  String value; // full value
};

then on parameters and other stuff:

struct Parameter {
 ...
   /**
      The translated names of this parameter.@n
      Must be terminated with a null TranslationString
    */
    TranslationString* translatedName;
 ...
};

tbh, I dont really know. I never had to do i18n. this will be a long-term thing, if we ever do it at all actually.

If it is only for LV2 might not even be useful, as we can just edit the ttl post-build.

[jpcima]

In the present case I think of LV2 only, and yes it can be post-build. There isn't currently a tool for doing this that I'm aware of.

If this is done externally, it would be a tool similar to the gettext suite, except dedicated to rdf processing.

For translation of plugin UIs themselves, I'm not aware of anything beside the JUCE translation system. It's just an extremely basic system of loading text files such as my text=my translation.