Daniel Schmeck writes: > I use the template toolkit for generating static html pages. At the > moment are all templates with german content. > > For the future I'm going to generate every page two times. One page with > german content, the other page with english content. Images, outgoing links, > layout are the same on both pages. The only difference is the translation of > the text. > > At the start of the web page the user can choose the german or the english > pages. If you choose the german pages the menu and the content is german. > > What's the best approach to doing this? Are there any plugins or frameworks > for this?
After having worked with multilingual sites for some time I'm pretty convinced that there is no "one size fits all".... It's all about asking the right questions: - Is it a one-off translation project or is it a living site where content is going to be added continuously? - How much dependency on a particular production process and web server do you allow? - Who is going to deliver content? My experience (some years old) is coming from sites which were intended to allow contributions by many people, most of them shunning to learn too much "markup", and where translations have been partially done by professional translators. So, use with care - YMMV. > If not, what options do I have to realize it myself? > > My source templates are plain text files . Are xml source templates better > for > internationalization? Not really. XML sources give you a wider range of tools to work with, but none of them has particularly good internationalisation support. With XML, there's a standard way to declare the language of an element with the xml:lang attribute. But the only difference to what you can do with other means is that it is a "standard". I have heavily stolen concepts which I've found in vanilla XML toolchains - for example the 'gentext' technique for internationalisation in the docbook XSL stylesheets. I guess the concept is older than that, but that's where I found it in the first place. The choice of input format depends on how much "markup" you have in your source documents. As soon as your source goes beyond a couple of lines, you'd want to have headlines (and some means to mark them as such), bullet lists, and so on. XML is *one* way to add markup, but not the only one, and not particularly friendly to the writer. This is mainly a question of the parser, and that's why I stick with TT: Perl has a parser for practically anything. In my ttree subtree I'm having XHTML sources, HTML sources, Docbook XML sources, POD, Usenet articles, and plain text, all at the same time. The most important point is that, whatever source format you choose, it keeps the authors (even if you are the only one) encouraged to contribute - and maintain - content. > I'm thinking over this options: > > a) different templates, > > b) multiple strings in the same template or > > c) multiple elements in a xml file. The key point is IMHO that you need different production strategies for different types of pages. If the page is mainly text (a "leaf" in the information tree) than I think it is best to have one file per language, with the language being specified either in the directory or the filename (both have pros and cons, depending on the target webserver, whether you want to allow using the site offline, etc...). This is almost essential if you consider that other people might be contributing contents, or translations. Good writers and translators are not necessarily good in XML, and even less likely to know TT. So this is cleary 'a)'. The templates defining the layout, the navigational structure and all auto-generated pages (index, glossary, ...) are different because they are likely to contain a higher portion of markup and "structure". You might want to maintain (and test) this only once, regardless of the number of languages you have. For these pages I have one source for all languages - and all texts are filled from variables. These variables are imported, depending on the language, by pre-processing a template "strings.$language". Almost, but not quite, entirely unlike b). I strongly argue against c) for the purpose of a web site. You are loosing too much plain simple information (e.g. the modification time of a particular language) if you collect all languages in one file. Though performance in the production is not extremely important for static pages, you wouldn't want your whole site to be re-processed just because you corrected a comma in the German version. You are likely to spend too much time for XML programming instead of writing contents if you want to add some post-processing to your files, e.g. adding a clickable table of contents. Finally, there are some technical XML quirks: If I have named anchors to the chapters of my source, I'd like them to have the same ID attribute in all languages (so that links to #bar are the same, regardless of language), but that's forbidden by XML. -- Cheers, haj _______________________________________________ templates mailing list templates@template-toolkit.org http://lists.template-toolkit.org/mailman/listinfo/templates
