[WM] multi language support?

[Justin Mason]

Chris said:

> Sounds good. One should be able to refer to contents url in other "output
> sets". These sets can also hold the information about the current output
> language. (Just writing down my thougts on this subject :-). 

Hmm...

I want to avoid having to add a way to "jump out" of the current URL set,
into other sets; it would be quite tricky (and messy to use).

I think this could be done by adding all content URLs to both the current
output set and a default output set, as they are defined.  If a content
URL is not present in the current set, but it *is* present in the default
set, then use the latter.

That way if a page is defined only in one content set, it's URL will be
accessible throughout all other sets, as long as it is not overridden in
that set.  (like a search path.)


> > Also you would need to keep copies called 'foo.title' (as before).
> 
> What content should it return? Should it depend on the language setting or
> always return some kind of default value? To me it makes more sense to 
> make the return value dependent on the actual settings.

Well, it should depend on the current language setting.

The idea is to cope with the case where the webmake file defines only a
LANG=de title -- in that case, even if the current lang is "en", "de"'s
the only title WebMake can return.

So for example if the user refers to "$[foo.title]", search for
$[foo.title##LANG=en] then fall back to $[foo.title].  Because the setting
code has set *both* $[foo.title] and $[foo.title##LANG=de] (or whatever),
there will always be *some* kind of title available in $[foo.title], even
if it's not in the correct language.  (might be worth printing a warning,
though, to note this to the builder.)


Actually, another thought.  What happens when you want to refer to a
metadatum in another language?  Will this be usable enough:

	$[foo.title##LANG=en]

Or should we think of another, more usable, scheme for the "LANG"
specifier?  (personally I think it's OK like this, although mildly
inconsistent with the other magic things that can be done in subst
references).  What do you think?

> By for now, I have to rummage your source ;-).

good luck!

--j.