Am 03.05.2010 03:34, schrieb Manuel Pégourié-Gonnard:
Another possibility is to handle language.dat.lua in the same way we handle
language.{dat,def} in TL currently. It would only require new (optional)
attributes for the AddHyphen postaction, and the code to handle it of course.
Pro: more modular and scalable. Con: needs coding.
Another approach: What about language.dat.lua being a database of files
containing the actual language entries grouped by language? That is,
split language.dat.lua into several language specific
language-<code>.lua files containing the declarations in the format
proposed by you and one language.dat.lua file that binds the
language-<code>.lua files together.
-- language.dat.lua
return {
["german"]="language-de.lua",
["english"]="language-en.lua",
["french"]="language-fr.lua",
...
}
-- language-de.lua
return {
["german"]={
loader="loadhyph-de-1901.tex",
patterns="hyph-de-1901.pat.txt",
hyphenation="hyph-de-1901.hyp.txt",
lefthyphenmin=2,
righthyphenmin=2,
synonyms={},
},
["ngerman"]={
loader="loadhyph-de-1996.tex",
patterns="hyph-de-1996.pat.txt",
hyphenation="hyph-de-1996.hyp.txt",
lefthyphenmin=2,
righthyphenmin=2,
synonyms={},
}
}
pro:
+ Grouping. All patterns concerning one language are grouped
together. For a pattern developer, who is typically interested in
one language only, there would be no alien entries in the way,
i.e., a file language-<code>.lua would be more easy to maintain
than the current language.dat(.lua) monster.
+ Local modifications for a single language would less likely lead to
side-effects for other languages. A package with experimental
patterns (dehyph-exptl as a use-case) could just provide a local
file language-de.lua with some entries modified or added and there
is no chance to breake other languages. Less stress for maintainers
and users who are ignorant about everything else than mother tongue.
+ This approach scales well with future non-standard hyphenation
patterns, that can be declared in the same language-<code>.lua files
without scaring people not speaking that language.
+ language-<code>.lua files could as well cover several languages,
i.e., <code> doesn't necessarily need to be a language code, but
could be more descriptive. This could perhaps be useful for
Cyrillic or Arabic languages (don't really know).
contra:
+ I haven't though about that.
+ More files, of course.
Best regards,
Stephan Hennig
