Re: Localization Structure Model



Bill Schroeder wrote:

Agreed. SQL seems overkill for this, and as pointed out, it makes it a
whole lot more work to work with the translation instead of when
everything is plain flat files in a cvs.

I have to disagree. Slashdot get how many hits a day? And they use MySQL on the backend. Besides, puting everything in the database simplifies translation and updates by simplifying web base forms for updates as well as notifications to the various translators that the page was updated.

Do you do translations? I do, and my opinion is that text files are _way_ easier. Just a couple of reasons:

* Translations can be used and updated from gnome cvs (with
  all advantages of cvs like versioning)
* Existing gettext tools can be used (if that solution
  is chosen)
* Just a simple text editor is enough to do translations
  (or would YOU like to be forced to do your coding in a
  form field in a browser all the time?)

As a simple exercise, please tell me how to do a search-and-replace in the form field...


Not to mention that language simply becomes a field in the database. Caching to flat files is fine but probably use much more often than needs be.

Do you realize that if we're speaking of all strings on the site (and we do, almost all strings should IMHO be translated) we're talking about a LOT of database queries here, even for simple pages? I cannot believe that this could be anything but much slower.


However, I don't know how well (if at all) MySQL or PostgreSQL etc... support

international character sets.

MySQL uses ISO-8859-1 (latin1) everywhere by default. But I guess this is kind of bad for those languages that don't use ISO-8859-1.


Christian



#######################################################################
Christian Rose
http://www.menthos.com                    	    menthos menthos com
#######################################################################





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]