[WM] multi language support?

[Chris]

On Sat, Nov 10, 2001 at 12:55:04PM +1100, Justin Mason wrote:
> 
> 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'm near the point to understand all that :-). 

> 
> 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.)

We'll see. It's not that important, you can always do it by separating your 
language trees by a certain prefix in the file system and then you know how to
access different lang-urls be rewriting the ones in your actual set.

> 
> > > 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.

The easiest way would be to make the first metadata the default one. If one
don't want to use the language feature, nothing changes. And we don't have to
rewrite the $[*.title] inference rules. 

> 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.)

Wheras this solution is the most comfortable one. Right now I'm implementing
the storage of the new meta data, according to your idea as 
$[foo.title##LANG=de]. This has also room for further extensions (if ever
needed).  I'd prefer making everything lowercase, but this are minor things, I
think.

One remark on this: to me it makes not that much sense to have fallback to
some language. I think in most cases it is a fault to use some kind of
fallback from $[*.title] to $[*.title##LANG=de] (and "de" not being the
current output setting). The other way round makes more sense. If there's no
special language setting, then use the 'main' title.  But don't infere it from
"other" language metadata. If it's not set then it's a fault. 

This implies that everyone using the language feature has to write
'language-aware' files as the '##LANG=' postfix has to be added everywhere.

So we have two sides to the problem: 1. to be $[*.title] a general fallback
for not defined language setting (e.g. the title is the same for all or most
languages), or 2. have a comfortable access to the current language setting
through $[*.title] as it is automatically set to actual language content.

Maybe this two versions can be implemented togethet, but I have to rethink
this.

> 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?

It's O.K. for me. The syntax is easy to use and easy to understand. 
Again we have to think of some fallback if this is not defined.

While analysing the source, there appeared some questions to me :-):

The $from parameter to most functions refer to the content item the
substitution was initiated from, doesn't it? But what are the magic 'from's
like "!M" and "!E" ?