At the moment we can support the switching of skins fairly easy, and to some extent the theming of those skins through switching CSS. However what we can't do is support picking up selected templates from several different skins.

For example (and this may be important to LocalizationFramework) I might want to pick up pattern skin, but with a gaelic translation of all the error messages. What I might do is to specify a skin search list - thus:

• Set SKIN = gaelic,pattern

Consider a search for the view template. It would look first for view.gaelic.tmpl, and having failed to find it search for view.pattern.tmpl, and ultimately view.tmpl.

A language-specific version of the view skin makes some sense, but what makes even more sense is a language-specific version of the error message templates. For example, DevelopBranch has the oopsalerts.tmpl template, which just contains error messages. If you provided oopsalerts.gaelic.tmpl, customising for languages could be as simple as changing the skin search path, and language could thus be set on a per user basis!

If you are smart about the text in the skin templates, then pattern skin contents could also be localised. Just %TMPL:DEF the strings in language.gaelic.tmpl and %TMPL:INCLUDE%{"language" at the top of twiki.pattern.tmpl, then <input type="button" value="

It would also be neat to switch in local customisations of skins. For example, I might elect to override just the view template locally with "tartan" skin in TWikiPreferences:

• Set SKIN = tartan,gaelic,pattern

or a personal skin just for me in my Users topic:

• Set SKIN = clanranald,tartan,gaelic,pattern

I haven't looked at the code in detail, but I suspect this would actually be quite straightforward to do.

Also, to keep things simple for the installer it would be nice to make the default language skin selectable in the LocalSite.cfg:

$cfg{Language} = 'gaelic';

• Set SKIN = clanranald,tartan,%CONFIG{"Language"}%,pattern

-- CrawfordCurrie - 03 May 2005

Crawford, this is an excellent suggestion. I have been struggling with small additions to existing skins that should just add on an existing template. But as with your language choices, the minute you do that you always fall back on ClassicSkin unless you totally recreate a new skin. Having a search path would solve that problem. (Well, not quite... the skins would have to be carefully designed to support "subtemplating" but that is another story...)

-- ThomasWeigert - 03 May 2005

I'd love to see this feature, although I'm not sure if it is the right way to do localization.

-- MichaelDaum - 06 May 2005

I would prefer not to create a skin for each localization - that would be a lot of overhead, and it would not deal with all necessary text, because a lot of strings are emitted from core code.

Still better would be a strings file with key/values for each language. Core code would need to look up strings from the strings file, and templates as well.

-- ArthurClemens - 06 May 2005

Arthur, I think you are misunderstanding Crawford's proposal. The suggestion is to make skins combinable. So if you have a skin for German, you would only create one template for German, where all the localization is taking place, but through the ability to combine with, say the pattern skin, you will get a full skin.

-- ThomasWeigert - 06 May 2005

I am trying to say that localization has nothing to do with skins. That you need to do it with skins now is a weakness of twiki.

-- ArthurClemens - 06 May 2005

Now I'm really confused.

'Localisation' is the blanket term used to refer to the process of making a software product fit better with the cultural or environmental constraints of where it is used. Thus, localisation covers character sets and the language used in strings and on buttons. It may also involve fitting the tool to a corporate environment, through specialisation such as corporate logos, colours, or fitting to a special needs environment (large fonts etc), or to a browser constraint (use on mobile phones, for example). TWiki uses skins for this specialisation. Skins are an essential part of the TWiki localisation strategy. In fact I would go so far as to say they are the localisation strategy.

What alternative did you have in mind?

BTW if you glance at oopsmanagebad.tmpl, you will see that it is exactly what you describe - a file of error strings.

I implemented skin paths. SVN 4273

-- CrawfordCurrie - 06 May 2005

Because buttons labels like Edit, Edit, strings like "All public webs", "Number of topics:" are defined in all sorts of places but not in templates. Even if you localize all templates to German you will get English labels everywhere.

oopsmanagebad is a good example of localization, because it just defines strings. But most other templates deal with painting the screen. Localize these, and you'll end up with an update nightmare. When Dakar comes out, or Edinburough, a lot of templates need to be redone.

Suppose we have strings defined in a central place, analogue to oopsmanagebad, but not necessarily in a template (could be a config file or topic), and library scripts read from that file before writing "Edit" on a button, that would be a lot more managable to localize, and keep it up to date.

The way Mac OS X applications do this, localization is done partly by editing the interface in the interace editor Interface Builder (a lot of work to do updates for each language I can tell you, especially if you decide to throw the interface upside down - should have done everything programmatically).
The programmatic part is what I am happy with: each language folder has a file Localizable.strings. This file contains lines of strings: key/ value pairs, like (in the English project folder):

"Select" = "Select";
"Yes" = "Yes";
"No" = "No";

and in the Italian language folder:

"Select" = "Seleziona";
"Yes" = "Si";
"No" = "No";

If somewhere a button needs to be drawn, the button text is being looked up from the correct Localizable.strings language version by calling a macro function: NSLocalizedString(@"Select", @"").

-- ArthurClemens - 06 May 2005

I understand all that, Arthur. I've tried to eliminate hard-coded language wherever possible, but there's a lot of legacy. However, to answer your point about language strings. Yes, you need to eliminate them from templates, but this is how to do it without any additional code. In strings.tmpl (english, the default)

%TMPL:DEF{"Select"}% Select %TMPL:END%
%TMPL:DEF{"Yes"}% Yes %TMPL:END%
%TMPL:DEF{"No"}% No %TMPL:END%

and in strings.italiano.italiano.tmpl (Italian localisation)

%TMPL:DEF{"Select"}% Seleziona %TMPL:END%
%TMPL:DEF{"Yes"}% Si %TMPL:END%
%TMPL:DEF{"No"}% No %TMPL:END%

The button is instantiated as <input type="button" value="%TMPL:P{"Select"}%" >. OK, the syntax is a bit clumsy, but it's no worse than what you describe above.

• Set SKIN = pattern

uses the default English strings, because there is no strings.pattern.tmpl so it falls back to strings.tmpl.

• Set SKIN = italiano,pattern

uses Italian because there is a strings.italiano.tmpl. The language is included from twiki.tmpl by adding the line %TMPL:INCLUDE{"strings"}%

Added a test and an example to the unit tests for templates ( test/unit/TemplatesTest.pm )

-- CrawfordCurrie - 07 May 2005

Yes, this would work.

-- ArthurClemens - 07 May 2005

Another thing on the same topic. The existing skin templates search searches in the web-specific dir first for both the skin-specific template and also the default template. Let's say I have template heeby and skin jeeby, and I'm in Myweb. The search will be for:

1. templates/Myweb/heeby.jeeby.tmpl
2. templates/Myweb/heeby.tmpl
3. templates/heeby.jeeby.tmpl
4. templates/heeby.tmpl

This makes it rather awkward to override the default template for a web without mangling the skin. This has been noted before by other people. So I'm proposing a change to this:

1. templates/Myweb/heeby.jeeby.tmpl
2. templates/heeby.jeeby.tmpl
3. templates/Myweb/heeby.tmpl
4. templates/heeby.tmpl

I don't believe this will impact anyone right now though it may have effects on some skins. But it's better to bite the bullet and get it right, than let the current travesty linger on.

In SVN 4275

-- CrawfordCurrie - 07 May 2005

Is there a way to let library files core code use strings from the strings template?

-- ArthurClemens - 07 May 2005

Yes; for example, to expand %TMPL:DEF{"Yes"}%, use $session->{templates}->expandTemplate("Yes"). It requires the strings template to have been loaded first.

-- CrawfordCurrie - 07 May 2005

to have been loaded first - does this mean we would have to put that include at the first line in the templates?

-- ArthurClemens - 07 May 2005

Yes, you would put it at the top of twiki.tmpl.

-- ThomasWeigert - 07 May 2005

Or you could simply ensure it was loaded as follows:

unless( $session->{templates}->haveTemplate("Yes")) {
   $session->{templates}->readTemplate("strings", $skinpath, $web);
}

(I used Yes as an example, but you could use the name of any other template that is only defined in strings.tmpl in the haveTemplate call)

-- CrawfordCurrie - 08 May 2005

Updated the documentation in TemplatesDotPm to match the new algorithm in SVN 4278.

-- ThomasWeigert - 08 May 2005

Crawford, the new search path handling seems to mess up statements in the templates as follows:

%TMPL:INCLUDE{"twiki.pattern"}%

but I need to study this some more. In either case, my extensions in SupportTopicSpecificTemplates do not work right any more with respect to template loading...

-- ThomasWeigert - 08 May 2005

Are there testcases? I added unit tests for the new load order in test/unit/TemplatesTests.pm. (That's not to say the testcases are correct, of course, it's just to say "please demonstrate the problem in a testcase and I'll fix it")

-- CrawfordCurrie - 08 May 2005

As I said, I'll study the problem and report back. Right now I don't have enough understanding yet... I'll come back to this... In either case, I like where this is heading...

-- ThomasWeigert - 08 May 2005

Crawford, I looked at the code and have some questions as to changes:

1. The first thing _readTemplateFile does now is to try to read the $name parsed into web and topic. This may be a good idea, but was previously done much later (also not in the doco).
   • I documented it as I coded it; it should be correct. I'll check
2. You do not allow to look for includes of the form %TMPL:INCLUDE{"twiki.pattern"}% by zapping the dot out of the name (the comment in the code says "zap anything suspicious").
   • That was there before I touched it..... I assumed it was protection against ../ in the name.

I can make it work with either changes, I am just curious. One (1) we would have to update the doco. On (2), I just wonder whether there will be every any need to include specifically skinned templates from another template?

-- ThomasWeigert - 08 May 2005

Haven't had time to really absorb all this, but I'd caution people not to use the templates mechanism as a way of storing localised strings - this is not going to be adequate in general (what about strings that require parameters, which TWiki uses in various places?), as discussed in LocalizationFramework.

I agree with Arthur that localisation (in the I18N sense, which IMO is the best definition) should be completely orthogonal to skin development, and the non-I18N-related customisations mentioned by Crawford. Getting all the strings translated for TWiki (including skins, core code strings, and so on) is more complex than just customising a skin for local requirements. I'd prefer to keep localisation and customisation separate - while in theory the same mechanisms can be used for both, in practice a parameterised string saying %d items found needs a proper LocalizationFramework.

Skin localisation should be completely orthogonal and separate to skin development - the aim should be to just take an existing skin, all of whose English text is in a suitable message catalog (LocalizationFramework defined), and have someone translate it. One benefit of using a standard LocalizationFramework is that there are tools to simplify translation work, organising the various strings to be translated so that anyone with a web browser can do the translations.

-- RichardDonkin - 08 May 2005

Jolly good. I'm just trying to suggest something that is practical and short range. I'd rather have something that mostly works now than have to wait 5 years for something that's perfect.

-- CrawfordCurrie - 09 May 2005

OK, I made param('skin') prepend to the skin path instead of replacing it. Everything seems to work as expected. I also changed it back to looking for web.topic much later in the code, and fixed the point about . in the skin name. Oh, and I updated the docs.

SVN 4298

-- CrawfordCurrie - 22 May 2005

i've set this to ReadyForMerge. if there are localisation issues (which is a proposed use of this feature, and not the feature itself) still needs work, that should be addressed in a new topic.

btw, i would love for DakarRelease to have a LocalizationFramework, and to ship german, french, italian, etc, etc, etc docs and skins.

-- WillNorris - 23 May 2005