[rt-devel] Localization

[Marco Nijdam]

Below my comments, for what its worth.

As quoted from Jan Okrouhly:
> On Tue, 4 Apr 2000, Jesse wrote:
> 
> > The most controversial part of that..and the part that I really just am not sure
> > about is the webui.  I'd like to do everything in my power to not have to
> > build multiple parallel localized versions of the webui. that would
> > just get way too cumbersome really quickly.  So. The ever-important question:
> 
> I'm not an i10n expert but I hope there will be some 'resource' files with
> localized texts for a given version of UI here. I think that some
> versioning will be needed to make a place for new patches from RT
> developers around the world (These couldn't be localized just in time be
> them ;-).

Resource files for things like error messages will be very useful.

> > 	Do we have any l10n experts in our midst? Anyone care to impart some advice?

I don't know whether you are planning to do so already, but consider
using templates for the Web UI as well. That way, people can localize
what they want, and even change the Web UI to their taste, without
a need to change the logic.

You will need a template processor to fill in the templates with
dynamic information (variables, query results). At least the template
processor need to replace variables. In the examples below I use a
variable respresentation of '$xxx.yyy$', but any will do.

There are at least two ways to approach this:

- Create a template per HTML page.
  This will require some special processing instructions within the
  template to indicate database queries, and most likely, conditional
  statements. E.g. (syntax is arbitrary, choose anything that can
  be easily parsed in perl)

	some HTML text ....
	#if $error.submit$
	You've submitted something illegal.
	#endif
	<table>
	<tr><th>nr</th><th>name</th>....</tr>
	#query name=overview
	<tr><td>$overview.nr$</td><td>$overview.name$</td>...</tr>
	#endquery
	</table>

  Within the logic you define the exact implementation (e.g. a SELECT
  statement on the database) for the query with name "overview".

  There are many template processors around that do this kind of
  thing. Some require database queries to be specified in the
  template, but I consider this bad practice. (Business) logic and design
  should be separated. The design should only need design-logic
  and only if really necessary.

- Create a template per HTML snippet.
  This will prevent the need for a #query type processing instruction,
  but you may get more template files to maintain, and maintaining
  the overview may be more difficult.
  An advantage may be that HTML snippets may be reused, e.g.
  a common header and/or footer.

Kind regards,
--
-- Marco Nijdam,       marco at west.nl
-- West Consulting bv, Bagijnhof 80,  2611 AR  Delft, The Netherlands
--                     P.O. Box 3318, 2601 DH  Delft
-- Tel: +31 15 219 1600, Fax: +31 15 214 7889