Greetings!

I've looked to problem tracking tool and choose the Gnats due to it
lightweight, modular, and robust backend. I'm newbie to Gnats
installation and administration. So when I've tried to deploy the PR
database (Gnats 4.0) on my corporate support site, I'm faced with l12n
and i18n problems. Gnats and Gnatsweb seems doesn't support non-english
messages at all, but my users are speaking Russian.


First, I need at least correct handling of non-ASCII characters.

Fortunately, Gnats tools uses is*() ctype functions and was linked
against libintl library (I'm use NetBSD), thus it correctly operates on
any 8-bit characters (16-bit ones should processed as two 8-bit chars).
But one problem still pursuit me - the e-mail notifications:

	1) Subject fileld must be MIME encoded.
	2) Message must contain charset specification.

So as my time was limited, I've just changed header{} at mail-format{}
section as follows:

	header {
	  format "Content-Type: text/plain; charset=koi8-r\nSubject: Re: %s/%s\n"
	  fields { "Category" "Number" } 
	}

I.e. Subject now doesn't contains synopsis text, and message have a
Content-Type field. 

Next, briefly looking over the code and documentation of gnatsweb.pl,
I'm found it was not really designed for non-english sites. Thus, two
new variables should fix this problem for me:

	site_html_language	- the language for returned web pages
	site_html_charset	- the charset for Content-Type

Depending on that variables (which had set values to "en-US" and
"ISO-8859-1" respectively) Gnatsweb now adds all corresponded headers
where needed. These variables are overridable from gnatsweb-site.pl.
Please see a patch provided in attachment.


Second, I need complete localization for Gnats. I.e. all messages, field
names, categories and so on should be easy changed by site's own values
on any preferred language. I'm personally have two ideas for this:

1) Add yet another field to Gnats PR structure: ">Encoding:". The Gnats
will use UTF-8, for example, as internal charset encoding. An encoding
for any newly arrived PR will be easy determined by this field and
autoconverted to UTF-8 using iconv library. User tools shoud specify
encoding when talking to gnatsd or when fetching PR in any way. The
directive "gnats-encoding" should be affected to all Gnats internal
data described below (field names, ...)

2) Use XML as internal format for database processing. This allows use
power and simplicity of XML i18n.

Indifferently to solution choosed, user tools must be adopted to this
behaviour (supplying and querying encoding values and so on).

Now I have a time to work on any of those (or any other) solution in way
to Gnats localization.


Any comments would be appreciated.

--
TIA, Mishka.