Note: Do not confuse multillingual strings, as introduced
by recent Dogelog Player, with Unicode encoding.
I am using the phrase "multilingual strings" for a text

database. Interestingly I managed to make the text
database declarative. Means the strings/3 entries
are not order dependent. You can place languages into
the multifile predicate in any order,

and it will pick the most specific string independent
of the order of the strings/3 facts. I was replicating
the Java Script Resource Bundle lookup on a finer
grained level, by this simple Prolog code:

get_string(Key, Locale, Value) :-
sys_locale_ancestor(Locale, Parent),
strings(Key, Parent, Res), !,
Value = Res.

% sys_locale_ancestor(+Atom, -Atom)
sys_locale_ancestor(L, L).
sys_locale_ancestor(L, M) :-
last_sub_atom(L, P, _, _, '_'),
sub_atom(L, 0, P, _, M).
sys_locale_ancestor(_, '').

The above assumes that locale identifiers use
underscore separator. It also assumes the last_sub_atom/3
predicate from Novacore, unfortunatel ISO Core has
only sub_atom/3, but no last_sub_atom/3.

For locales, see also:

Creating global software: Text handling and localization
in Taligent’s CommonPoint application system
Mark Davis et al. - 1996
https://dev.antiguru.de/davis.pdf

I wasn't sure whether the get_string/3 implementation
will perform. In Jekejeke Prolog, since it has
multi-argument indexing, each string/3 lookup with

mode (+,+,-) will be a little bit faster, whereas
Doglog Player, which has only first argument indexing
will use a little bit more time, since it needs

a scan, can only lookup the Key via an index,
but will scan for the Parent. If the text database
isn't extremly large and/or if the locales do

not have extremly many segments, this is a
non-issue I guess. And Dogelog Player might get
multi-argument indexing in the future.

Mild Shock schrieb:
> Note: Do not confuse multillingual strings, as introduced
> by recent Dogelog Player, with Unicode encoding.
> I am using the phrase "multilingual strings" for a text
>
> database. Interestingly I managed to make the text
> database declarative. Means the strings/3 entries
> are not order dependent. You can place languages into
> the multifile predicate in any order,
>
> and it will pick the most specific string independent
> of the order of the strings/3 facts. I was replicating
> the Java Script Resource Bundle lookup on a finer
> grained level, by this simple Prolog code:
>
> get_string(Key, Locale, Value) :-
> sys_locale_ancestor(Locale, Parent),
> strings(Key, Parent, Res), !,
> Value = Res.
>
> % sys_locale_ancestor(+Atom, -Atom)
> sys_locale_ancestor(L, L).
> sys_locale_ancestor(L, M) :-
> last_sub_atom(L, P, _, _, '_'),
> sub_atom(L, 0, P, _, M).
> sys_locale_ancestor(_, '').
>
> The above assumes that locale identifiers use
> underscore separator. It also assumes the last_sub_atom/3
> predicate from Novacore, unfortunatel ISO Core has
> only sub_atom/3, but no last_sub_atom/3.
>