Issue 2284

Title
Allow to define table to store translation values
Priority
feature
Status
chatting
Nosy list
ced, nicoe, sharoon
Assigned to
Keywords

Created on 2011-11-13.17:11:02 by ced, last changed 2 months ago by ced.

Messages

Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2022-04-16.01:34:17

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.

Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2017-04-10.11:01:10
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.
Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2014-03-22.01:36:27
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.
Author: [hidden] (nicoe) Tryton committer
Date: 2014-03-22.00:29:26
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.
Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2011-11-13.17:11:01
As issue2283 but for translation table.
History
Date User Action Args
2022-04-16 01:34:17cedsetcomponent: + trytond
messages: + msg75820
priority: wish -> feature
2017-04-10 11:01:10cedsetmessages: + msg33174
2014-03-22 01:36:28cedsetmessages: + msg16277
2014-03-22 00:29:27nicoesetstatus: unread -> chatting
nosy: + nicoe
messages: + msg16276
2011-11-13 17:11:02cedcreate

Showing 10 items. Show all history (warning: this could be VERY long)