Search issue with translated plugins

[trebmuh]

See https://github.com/brummer10/jalv_select/issues/39

---

Notes from drobilla on IRC #lv2:

Since the only particularly feasible solution is to load all translations into memory at once, which aside from massively increasing memory usage would probably require a bunch more work to not making a bunch of other things tedious, it's kind of an academic question
I'd rather see a precedent of using a non-translated identifier for such things
If URIs are too tedious for that (which they probably are), symbols like "calf.reverb" or some such are what I'd like to see
That said, sure, particularly these days, free-form text search is kind of expected for everything, but the cost:benefit of this specifically with respect to the language thing doesn't seem great to me
But lilv, probably.  It would be possible to add an option to load everything if hosts really want to
Doesn't really seem to have anything to do with jalv
It might not be so bad if it's only for the untranslated (which is not "english" in anything but convention) and translated name
I have no idea how the search in jalv_select works

[trebmuh]

pinging @brummer10 here

[brummer10]

regardless how search works in jalv_select: https://github.com/brummer10/jalv_select/blob/master/jalv.select.cpp#L857-L895 it would be nice if we could set a language LANG in lilv, so that lilv returns the nodes matching, instead all in arbitrary order. Fallback will be of course English.

[drobilla]

it would be nice if we could set a language LANG in lilv, so that lilv returns the nodes matching, instead all in arbitrary order. Fallback will be of course English.

I'm not sure I understand what you mean here. If you mean the current behaviour of "automatically" choosing the correct translation based on LANG (otherwise the translation would be broken for existing hosts).

There is an option to disable the language filtering: LILV_OPTION_FILTER_LANG. With this unset, it should be possible to implement the desired behaviour, but the host will have to do the language filtering itself.

[brummer10]

I mean a option to setlocale() for lilv. https://man7.org/linux/man-pages/man3/setlocale.3.html To allow the host (the user) to select a language other then the system language. I've tried LILV_OPTION_FILTER_LANG and expected that lilv returns then ALL names, when I ask for lilv_plugin_get_name() for example, but it seems that lilv just return one name, and you'll never know which language it is then.

[drobilla]

Why would a host want to use a different language than the system one?

[brummer10]

The request to allow a user to select the language is in the opening post of this issue. Implementing a function to setlocale() in lilv would be very easy and wouldn't harm current host implementations.

[drobilla]

The issue is about searching multiple languages. I don't think repeatedly changing the LANG of Lilv is a good way to do that.

I've tried LILV_OPTION_FILTER_LANG and expected that lilv returns then ALL names, when I ask for lilv_plugin_get_name() for example, but it seems that lilv just return one name

How would a function that returns a single node return all names? Use lilv_plugin_get_value with filtering off.

[brummer10]

How would a function that returns a single node return all names? Use lilv_plugin_get_value with filtering off.

Return whether a feature is supported by a plugin. This will return true if the feature is an optional or required feature of the plugin. ?? The issue is about that users may not know the translated name of a plugin for there native language. Then allow to search for the original English name may be a option.

However, please don't forget, I'm not the one who open this issue, if you don't interested into solve it, I'm fine with it, less work for me as well.

bye

[drobilla]

I understand what the issue is and suggested a solution. You then posted the documentation for a completely unrelated function - for some reason - and go passive aggressive about it?

If this is how you communicate about issues, then indeed, I am not interested in solving it for you.