Created on 2011-11-13.17:11:02 by ced, last changed 2 months ago by ced.
I just found https://github.com/odoo/odoo/pull/88364.
I guess we could have a derived Char and Text fields which are stored as JSON in the database using language code as key.
Those fields would be used on non-system model that needs translation like the product name. But we should keep the current
ir.translation table for the system like the model, field and view translations because it provides a good way to create and update the po file from the code.
Of course such implementation would need to provide the tooling to convert existing translated Char and Text into JSON.
The MultiValue fields could be used for some specific field like the product name. About msg16276, it will be good to have the query explanation to see where is spent the resources.
I think the auto-completion should probably start only after 3 chars. About the coalesce, the problem is that we show the default language value in the client in case of missing translation but of course it is for non fully translated application which should probably not be considered as the norm.
We currently have an issue where a simple search (%b%) on the rec_name of the product table (with nearly 300k records) is pretty slow because the translation table enters in the game. I made some tests with different schema structure / way to query the database. In order to have a large amount of data I used /usr/share/dict/words to have a lot of rows. Redesigning the translation schema does not change much the performances, the most important performance gain I obtained was by changing the way the query is structured (instead of a "in (select …)" I used a join) but those performance improvement where not really good (≃ 15-20%). I also tried using a trigram indexes but they began being usefull once the length of string searched is ≥ 3 and they require to stop searching also in the original table (no use of the COALESCE). Event if at first I though that dropping the coalesce was a bad idea, in the end I guess that user that insist on using another language then the default one do not want to see another language in their interface for fields that are translatable.
As issue2283 but for translation table.
messages: + msg75820
priority: wish -> feature
|2017-04-10 11:01:10||ced||set||messages: + msg33174|
|2014-03-22 01:36:28||ced||set||messages: + msg16277|
|2014-03-22 00:29:27||nicoe||set||status: unread -> chatting|
nosy: + nicoe
messages: + msg16276
Showing 10 items. Show all history (warning: this could be VERY long)