> About autoconversion: > > Changing the encoding of text files is pretty easy. For example: use > the 'recode' tool. An alternative would be to extend the IDE to > load/save files of other encodings and extend the compiler to auto > convert the strings. > After that you must check all places, where fixed visual character > widths are used. In lazarus only synedit and parts of the widgetsets > were affected. So, although is not difficult, this part can not be > done automatically. Yes, this may be a problem. This is another argument to make a compatibility mode.
> >> [...]instead of having 2 sets of components for each encoding, > > > Ansi and UTF16 and options to use UTF8 instead > > > of Ansi, > >[...] > > (you must be sure, both students and > > post-graduates will be strongly disappointed if they will see English > > messages, and they will be disappointed much more if they would see > > somewhat like ЪЪЪЦЪЪЪЪЪЪ). > > This is the current situation (as soon as you switch to another OS). > That's exactly what the switch to one encoding should fix. Should fix. Only if such text is not placed directly. > It will reasonably work. For example you can not expect that the > current windows font supports all languages. But this can not be fixed > by the LCL anyway. And this code SHOULD work good (this is a bad code for international projects, but a real code for small national projects). If you say that this code won't be supported anyway, I will prefer old good versions (or patched current). > > > And the same will > > be with Application.MessageBox? If you are, how will it be with those > > who have a tons of code (easily converted to UTF8, as you say) full > > with Windows.MessageBox(Handle,...) which means MessageBoxA? > > AFAIK the call to Windows.MessageBox is not the problem, but the non > UTF-8 strings stored in databases. If stored - yes. If not - no. Will you store any message in "quickly made" application? > Conclusion: > Switching to UTF-8 means writing i18n programs becomes much easier and > writing system specific programs becomes harder. It breaks > compatibility. Some people would like a simple switch and that the LCL > should support both, but lazarus has not the man power to support this. > This switch is quite simple... Besides, my recoding "work around" - encoding conversion application for the whole directory (from prev.post)
cptr.tgz
Description: Binary data
