Is this a Globalize bug ?
Posted by Sandro Paganotti in
no comments
While installing Globalize I stumbled upon the plug in’s table structure. If we look at the ‘tr_key’ field inside the table ‘globalize_translations’ we may notice that this field type is ‘VARCHAR (255)’ (obviously only under mysql but I think this is the database chosen by the majority of rails developers).
Hey, but isn’t this column the one holding the strings to be translated?
The answer is (ASAIK) yes, in fact if we look inside file ‘view_translation.rb’ (inside the plug in’s models’ folder) we spot this piece of code:
def self.pick(key, language, idx, namespace = nil)
conditions = 'tr_key = ? AND language_id = ? AND pluralization_index = ?'
namespace_condition = namespace ? ' AND namespace = ?' : ' AND namespace IS NULL'
conditions << namespace_condition
find(:first, :conditions => [conditions,*[key, language.id, idx, namespace].compact])
end
Wow, the ‘tr_key’ is used also to store and (as shown here) retrieve translations from the db; but what happens if the string I’m trying to translate exceed the 255 chars limit?. Simple, the string get saved on the database truncated at its 255th character, then when the plug in try to search for this string obviously it didn’t find anything (‘cause it’s looking for the whole string, not its first 255 chars); the result? A string longer than 255 chars never get translated plus it creates a duplicate row each time is called its ‘t’ method.
The fix I coded is pretty easy:
def self.pick(key, language, idx, namespace = nil)
conditions = 'tr_key = ? AND language_id = ? AND pluralization_index = ?'
namespace_condition = namespace ? ' AND namespace = ?' : ' AND namespace IS NULL'
conditions << namespace_condition
find(:first, :conditions => [conditions,*[key[0...256], language.id, idx, namespace].compact])
end
In this way you just need to be aware of long string with the first 255 chars in common; but this is quite rare, so you can easily ignore it.
Sandro
