From: Victor Boctor <vboctor@gm...> - 2006-11-09 07:20:41
cc'd dev mailing list.
Thanks a lot for your effort with this. Please find some questions inline.
On 11/7/06, Alexey Chumakov <alex@...> wrote:
> Hi Mantis devs (and users),
> Approaching to Unicode support planned in 1.1, after some testing in my
> working environment,
> I've finally converted all the strings files to utf-8 (in cvs head).
> So any NEW (and upgraded) installation could use any national chars
> correctly with any language.
> The languages settable thru UI or autodetection are all utf-8.
> There is currently no easy way to upgrade the already entered text in
> existing installations (all
> non-latin characters already in database will probably break).
We need to avoid such breakage. By default we should continue to use
the old files unless we know that it is safe for the specific language
to auto-convert to UTF8. There is two ways to do that:
- Keep the utf8 prefix as before and just make all languages have a
utf8 version. This is not what you have done.
- Go with the naming convention that you have used, but add database
upgrade steps that renames old language values that will break to the
new values which include the encoding.
In both scenarios we should have all new languages use UTF8 languages
As for the "auto" detect, I am not too worried about changing it to
map to UTF8 rather than the previous language files.
> For that reason, legacy non-utf8 string files are still included, and you
> can use them via config_* if needed.
> It is possible to convert the entire database manually (unloading it to the
> text file, converting with iconv
> and loading back), but, of course, I can not recommend this in production
Unless we have an upgrade step to convert to the UTF8, we should
continue to support the old encodings.
> I've also removed 2 of string files: the non-unicode Italian translation
> (reported to be obsolete),
> and the Canadian French one (diff showed no differences from French).
We need to add an upgrade step that converts the language preference
for the users that had these removed languages selected.
> Please report any inconsistencies found.
> Any help with writing the db upgrading routine is welcome.
> Also, please do NOT update non-utf8 language files anymore as they are
> considered deprecated.
Given the number of installations out there, we may find that if we
don't provide an upgrade we may still have to support updating the old
From: Richards, Paul <plr@la...> - 2006-11-09 08:50:43
> > It is possible to convert the entire database manually=20
> (unloading it=20
> > to the text file, converting with iconv and loading back), but, of=20
> > course, I can not recommend this in production environment.
> Unless we have an upgrade step to convert to the UTF8, we=20
> should continue to support the old encodings.
Bear in mind that we also support pgsql+mssql, which may deal with UTF8
differently to mysql.