[WM] multi language support?

Justin Mason jm.jmason.org
Mon Nov 12 23:23:02 GMT 2001


Chris said:

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

Sounds OK!

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

BTW I'd be happy with lowercase "lang" as well, so go with that if you
prefer!

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

OK -- makes sense.  (and would avoid confusing multi-lang pages ;)

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

I think 2. is important, BTW.  Also I reckon they can be both implemented
together... instead of setting both $[*.title] and $[*.title##LANG=de] at
set-time (as proposed before), modify the lookup to search first with
"##LANG=de" appended, then fall back to without.

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

The "from" parameter is used to track dependencies so files can be rebuilt if
any content item they depend on, is changed.  Those "magic" ones mean
respectively:

$SUBST_EVAL             = '(!E)';	# evaluated code, always rebuilt
$SUBST_DEP_IGNORE       = '(!D)';	# ignored for dependencies
$SUBST_META             = '(!M)';	# metadata defined on an <out> block

(defined in Main.pm).

$SUBST_META is special, in that it's metadata defined on an <out> block in the
webmake .wmk file, and is ignored. (not sure why I didn't just use
$SUBST_DEP_IGNORE, but there you go ;)


BTW a thought has occurred to me.  It would be best not to use ## as the
separator, as it's already used in EtText to denote <code>...</code>, and it's
not good to give 2 meanings to 1 token :( Maybe something else like :: (C++
style)?

--j.




More information about the Webmake-talk mailing list