Currency not Latin fields issue #739
Comments
|
it works fine for mac |
Also incorrect code
wxTRANSLATE(...) only for name needed. Should be
|
@stef145g could you reproduce this issue? |
I have now tested this and it works to some degree but this is not the solution. I have created a temporary branch: https://github.com/stef145g/moneymanagerex/tree/test_only_non_functional
When starting the program and immediately creating a new database, the new currencies will be added. I have found that initial EUR character is wrong, but the EUR1 character is correct. Still not sure why. Just splitting DB_Table_Currencyformats into a .h and .cpp file is not the solution. |
I've converted DB_Table_Currencyformats_V1.h file to UTF-8 by Notepad++ Now there are a lot of warnings appears:
But
helps to fix this warnings but at the same time a correct encoding lost. |
it's already UTF-8... |
There are two UTF-8 with BOM and without |
How to implement this changes?
|
It's vital to note that
unacceptable to use. |
@vomikan does this issue happen on Linux version? |
Final call here:
L prefix should be added to all non Latin strings
|
Personally, I believe that all non Latin symbols should go away from source files. |
Related fixes: moneymanagerex/database@618281a |
would we close it right now? |
It's still a mess |
@guanlisheng please remove all entries of wxTRANSLATE("") from py file then update the code and po files. There are many helpless string present now (about 500 like "." "," "$U" "Céntimo" "دج" etc). |
how is everything going after some wxTRANSLATE removal? |
Working file |
There is a source of CURRENCYFORMATS_V1 table inserts:
The Python script wrap all latin values into wxTRANSLATE.
Problem: Nobody needs translations of ISO codes and currency names as well and nobody will translate so huge amount of strings.
This technology is OK only for Categories!
|
I suggest mark field that to be translated special symbols like "€ £ ₴ ؋ ¥ ...."
Accordingly, the Python script should be changed .
should be added and file charicter encoding should be UTF8 with signature. |
Currency values are initialised when the table is created. While we have a problem with the initialisation, this does not fix existing or old databases. The only way to fix existing databases is to rewrite the existing data in the currency lookup table. The problem with doing this is that in some databases, the existing currencies will be replaced and these may not correctly align with the new currency definitions created on initialisation/readjustment. The only way around this is to discover what files are affected, make the change then manually readjust the currency for each account that has been realigned with an incorrect currency, including the base currency. MMEX version 1.3.x has a new command Database Debug under Tools / Database These two files have been provided to fix this problem as follows:
|
The problem in currencies for new DB (created exactly in v 1.3.x) |
I have used this procedure to fix my working database that was created at Version 0.9.6.0 While this is not the total solution, it is a valid solution for all existing databases created prior to 1.3.0 |
Agree with Nikolay for new databases, we need to modify script in some way to identify field that needs translation. Regarding fix existing DB, why not simply release a DB upgrade version with something like this (pseudo-SQL): |
Checking further: the problem is not with python because the resulting DB_Table_CURRENCYFORMATS_V1 file is encoded as utf-8 The resulting code is :
I have separated the command in two to see the result of 'euro' Using the same line of code where I define euro to see the resulting string, the utf-8 character is OK when added to the call before calling the .h code. I suspect it has something to do with how utf-8 code is used in wxWidgets. There is a call where the code is passing a wxString but expects a const *char and the conversion is getting corrupted within wxWidgets. |
@gabriele-v Your method would be OK when the database has all its currencies set. Some of the old databases are more than likely, still being used (Mine being a classic example) that will not have all the currencies installed. Also any new database created will have the same problem, unless after being created on the 2nd run the database is immediately upgraded. |
@stef145g
I know that second won't fix all DBs (older ones don't have ISO code populated) but this issue seems to occur only after we have inserted translations into DB_Table_CURRENCYFORMATS_V1.h, so every DB created in this way has ISO codes too. Older DB will still remains without all currencies, but at least we can solve problem on recently created DB. |
Taking up @vomikan 's suggestion, sqlite2cpp.py has been modified to provide the correct output for building the .h files. The database definitions in table_v1.sql for translations have been modified. Data requiring translation require a Ref: #1024 Pull Request |
fix(Issue.#739): Currency not Latin fields issue
Now it working as expected. |
The text was updated successfully, but these errors were encountered: