[geeklog-devtalk] Multilingual CMS

[Tony Bibbs]

Euan, not to be a pain but what is the critical flaw with Translation2 
that keeps you from considering it?  To be clear, there are a number of 
translation libraries and I have no intention on maintaining that code 
in Geeklog 2.  In fact I'm opting for 3rd party libraries to do as much 
of the work as possible. 

So please, give some of the limitations of Translation2 because, 
frankly, it seems quite capable.

Also, let's not confuse the topic too much as there are two issues in 
this thread now.  The first is how to best translate items from look-up 
tables, the other is the choice of a translation librar in the first place.

--Tony

Euan McKay wrote:


> Tony,

>

> Sorry for the delay, having a busy week. As if that's only me... :)

>

> I'll have a dig on Saturday for translation systems and see what other 

> CMS are doing/if there is anything other than the PEAR system out 

> there. I'm sure there must be some discussion on a mailing list 

> somewhere on this kind of thing.

>

> If not, I can separate out the stuff I've written for the next Glinks 

> plugin (which supports multilingual content) and make that a 

> translation system.

>

> Cheers,

>

> Euan.

>

>

> On 2004/12/15, at 6:50, Tony Bibbs wrote:

>

>> Euan, figured I'd ping you since I haven't heard back yet.

>>

>> --Tony

>>

>> Euan McKay wrote:

>>

>>> Tony,

>>>

>>> Don't want to sound like a stuck record here.... but....

>>>

>>>> CREATE TABLE list_of_values (

>>>>   lov_id int(10) unsigned NOT NULL auto_increment,

>>>>   group_name varchar (30) NOT NULL,

>>>>   short_name varchar(30) NOT NULL,

>>>>   description varchar(128),

>>>>   enabled tinyint(1) NOT NULL DEFAULT '1',

>>>>   sort_order mediumint(10) NOT NULL DEFAULT '0',

>>>>   PRIMARY KEY (lov_id),

>>>>   INDEX (group_name)

>>>> ) TYPE=INNODB;

>>>

>>>

>>>

>>> Can we make the "description" and "*_name" columns into ids looked 

>>> up from a DB table? Even if this table is primarily for items that 

>>> only admins will see, and not all values are used in all cases, in 

>>> the interests of multilingual sites....

>>>

>>> Also, I'm not aware (as I haven't really looked) of any packages 

>>> that handle translation for items in the DB. Anyone know of any 

>>> other than Translation and Translation2 that seem to require 

>>> PEAR:DB? Also, is the multilingual capability of GL2 considered 

>>> important by the developers? (what I'm asking, in the nicest 

>>> possible way, is - is it just me who's paranoid about this? :-)

>>>

>>> Cheers,

>>>

>>> Euan.

>>>

>>> *************************************************

>>> Heather Engineering - no job too small

>>> http://www.heatherengineering.com/

>>> info at heatherengineering.com/

>>> *************************************************

>>>

>>> On 2004/12/14, at 5:33, geeklog-devel-request at lists.geeklog.net wrote:

>>>

>>>> Message: 5

>>>> Date: Mon, 13 Dec 2004 13:31:10 -0600

>>>> From: Tony Bibbs <tony at tonybibbs.com>

>>>> To: geeklog-devel at lists.geeklog.net

>>>> Subject: [geeklog-devel] Look-up Tables in GL2

>>>> Reply-To: geeklog-devel at lists.geeklog.net

>>>>

>>>> Today in GL 1.3.x we have a number of look up tables (e.g. 

>>>> gl_postmodes,

>>>> gl_cookiecodes, gl_featurecodes, etc).  All nearly look exactly the 

>>>> same

>>>> in terms of their structure but they serve wildly different needs.  In

>>>> GL2 I'm proposing we use a single table to serve all those needs.  

>>>> This

>>>> isn't anything 'new' in concept but it is new to GL.  Anyway I call 

>>>> this

>>>> table the List_of_Values table and it would look roughly like this:

>>>>

>>>> CREATE TABLE list_of_values (

>>>>   lov_id int(10) unsigned NOT NULL auto_increment,

>>>>   group_name varchar (30) NOT NULL,

>>>>   short_name varchar(30) NOT NULL,

>>>>   description varchar(128),

>>>>   enabled tinyint(1) NOT NULL DEFAULT '1',

>>>>   sort_order mediumint(10) NOT NULL DEFAULT '0',

>>>>   PRIMARY KEY (lov_id),

>>>>   INDEX (group_name)

>>>> ) TYPE=INNODB;

>>>>

>>>> I don't think there will be much argument over the structure but I

>>>> wanted to make sure this made sense to everybody.  The issue I really

>>>> wanted to discuss was one brought up by someone recently (name escapes

>>>> me) on how to handle the translation of text stored in drop downs.   I

>>>> have been assuming we would pipe the text in the actual database table

>>>> through our translation library...seems simple enough but I wanted to

>>>> make sure I wasn't over looking anything.

>>>>

>>>> --Tony

>>>

>>>

>>>

>>> _______________________________________________

>>> geeklog-devtalk mailing list

>>> geeklog-devtalk at lists.geeklog.net

>>> http://lists.geeklog.net/listinfo/geeklog-devtalk

>>

>>

>>

>> _______________________________________________

>> geeklog-devtalk mailing list

>> geeklog-devtalk at lists.geeklog.net

>> http://lists.geeklog.net/listinfo/geeklog-devtalk

>>

>>

>

> _______________________________________________

> geeklog-devtalk mailing list

> geeklog-devtalk at lists.geeklog.net

> http://lists.geeklog.net/listinfo/geeklog-devtalk