[PyQt5] Translate QCombobox
-
Hi
I would like to translate an app.
Right now, I am using QTranslator and QTLinguist and most of the translation is ok.The only part I can not translate is few QCombobox in this application.
These combobox get the list of item to display from a sqlite database (text stored in English) and I would like to be able to display these items in local language.
I do not know how to handle this situation, if you have an idea ?
-
Actually, I finally chose a simplier solution.
The main reason is that :- I do not want to modify the database structure
- I want to make it easy to translate theses combobox
So my solution is to use a dictionnary,
- this dictionnary will be used to initialise the database (in english
- using keys, I can choose which langage to display
- this dictionnary is stored in a json file (easy to edit by translator)
-
Hi,
The simplest would be to provide that part of the translation through the database itself so it allows you to more easily provide updates for that data.
-
@Denni-0 while I don't disagree with the logic of the implementation, it might be a bit overkill. Having one column per translation could be enough and would allow a direct use in the combo box by just changing the column used.
-
@Denni-0 as I wrote before, I don't disagree with the logic you are proposing. I just encourage to analyse the needs before creating a relational scheme that may or may not be overkill depending on the amount of data, the translation method used and the scope of the data.
Out of curiosity, in what way do your consider a call to setModelColumn more complicated than your proposal ?
-
If the OP is prepared to define a SQL
VIEWin the backend, which presents the data as columns for the convenience ofQComboBox.setModelColumn(), this allows (to some extent) independence from whether the underlying table is stored with columns or rows for the languages, so he can either way on the implementation :) -
@Denni-0 said in [PyQt5] Translate QCombobox:
If you mean setModelColumn is a reference to a column in a row within the a table within a database its not more complicated -- the complications come into play when you need to add a new column that did not exit before or remove one that currently exists
"A column in a row within a table with a database" does not make much sens. SQL wise, using a QSqlTableModel, you just say which column of said model (and thus table) you want to use and the combobox will show you that.
I am wondering if we are on the same line with regards to my suggestion. The table I was talking about would be (if using SQLite):
create table items(id integer primary key, english varchar, german varchar, french varchar);One column per language supported.
One thing for sure is that if you want to add or remove a supported language it will require a migration of the database. No doubt about that. However adding and removing items will only concern one row.
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
@Denni-0 said in [PyQt5] Translate QCombobox:
If you mean setModelColumn is a reference to a column in a row within the a table within a database its not more complicated -- the complications come into play when you need to add a new column that did not exit before or remove one that currently exists
"A column in a row within a table with a database" does not make much sens. SQL wise, using a QSqlTableModel, you just say which column of said model (and thus table) you want to use and the combobox will show you that.
I am wondering if we are on the same line with regards to my suggestion. The table I was talking about would be (if using SQLite):
create table items(id integer primary key, english varchar, german varchar, french varchar);One column per language supported.
One thing for sure is that if you want to add or remove a supported language it will require a migration of the database. No doubt about that. However adding and removing items will only concern one row.
@SGaist said in [PyQt5] Translate QCombobox:
One column per language supported.
What I guess @Denni-0 is trying to show with your approach is that when you need to add a new language to the DB you need to alter the table structure just to add a new column.
if you want to add or remove a supported language it will require a migration of the database.
Not using @Denni-0 approach, you just add more rows for the new language or delete all rows for an existing language. No changes to table structure (no need to use DDL commands)
-
@Pablo-J-Rogina I know exactly what @Denni-0 is explaining. You'll need one table for the language identification, one for the words and one for mapping the translations together because you'll want to have one as reference for further processing along and people will also be expecting that you have the items in the same order whatever the language. Therefore you structure should allow to grab all data in the same manner without having to worry which language you are using. You can always add sorting at the end if you really want to but that should rather be an option for the user.
In the same answer you are quoting, I already explained (and insisted on) the need of a migration (structural change / data change) of the database if a language is added or removed.
Again: I am not saying that @Denni-0 method is wrong or bad nor that my proposition is superior.
It's just two solutions with pros and cons to take into account.
-
I am not using MVC ?
QComboBox -> View
QSqlTableModel -> Model
Database -> source of data for the model.There's no controller layer here because Qt uses Model/View rather than Model/View/Controller.
You can use QSqlQueryModel for more involved queries like the one needed by your design. So you can combine QSqlQueryModel and QComboBox and there you have your MV pattern.
Neither QSqlQueryModel nor QSqlTableModel cares about what database backend you are using.
In any case, whatever technique you use, you have to configure database access before you can query it which is valid for any other generic framework you use to access a database (SQLAlchemy, Django's ORM, QtSql module, etc).
Are you suggesting to query the database and generate the list of combobox entries based on the values returned by that query ? In what way does it untie you from the database ?
In any case, please explain how you would populate that combo box with data coming from an SQLite database.
-
@Denni-0 said in [PyQt5] Translate QCombobox:
No because in Qt the Model and View actually are not separate and also actually represent View/Controller joined into one entity -- so it being called a Model is wrong -- further this means that when you tie the database to that you have a single entity that represents View/Controller/Model -- a single entity not 3 separate entities
That statement is pretty wrong. Qt's View classes are just GUI elements that shows one way or anther the content provided by a model. You don't need a view to use Qt's models. However I do agree that these models can contain elements that can modify the rendering of the view. But still they are not one entity as you write. A QTableView is a widget to show the content of a table like model (base on QAbstractTableModel, QSqlTableModel, etc), a QComboBox is a view on top of a model that has at least one column (again QAbstractTableModel, QAbstractListModel, QSqlTableModel, etc). Whatever feeds the model is of no concern to either QTableView, QComboBox or any of the other view you can put of on top of these models. Take the QFileSystemModel, it's a threaded model that loads filesystem content "on demand".
Anyway, I am not promoting anything, I am discussing possibilities.
If anything I am using the tools Qt proposes. Are they the only way to work ? Not at all. Are they always the best solution, again, not at all.
I usually take the time to ponder what tool is the best for the situation at hand. Taking a sledgehammer for every type of nails is not the correct methodology.
-
Actually, I finally chose a simplier solution.
The main reason is that :- I do not want to modify the database structure
- I want to make it easy to translate theses combobox
So my solution is to use a dictionnary,
- this dictionnary will be used to initialise the database (in english
- using keys, I can choose which langage to display
- this dictionnary is stored in a json file (easy to edit by translator)
-
Actually, I finally chose a simplier solution.
The main reason is that :- I do not want to modify the database structure
- I want to make it easy to translate theses combobox
So my solution is to use a dictionnary,
- this dictionnary will be used to initialise the database (in english
- using keys, I can choose which langage to display
- this dictionnary is stored in a json file (easy to edit by translator)
