Closed Ricky-Tigg closed 1 year ago
In fact, the locale is an experimental feature which was suggested by one of my colleague. In implementing that feature, we found that the translation is not easy because most of the words are professional and unique. For example, I could not find proper translation for "Spalart-Allmaras" turbulence model. The only way to translate it is just to write its pronunciation in Korean, which I didn't like. Do you have any idea?
Last night, I came up with an idea that to mix English letters with others may not look so strange as long as the languages use similar letters. What do you think about it? As you may Know, the characters of North East Asian countries such as China, Korea, and Japan have quite different characters from English letters.
At morning, here, your thought sounds to me coherent and worth to apply. I was to suggest in reply to your previous comment somehow a less sophisticated and desirable practise that has root in minimalistic approach; the source translation file, which i assume is in English {either United Kingdom or USA}, would expose to translation solely expressions that are non-ambiguously eligible for translations, e.g. bicycle, pork, car, wind, Korea, settings; they indeed invariably produce non-ambiguous expressions, respectively polkupyörä, porsas, auto, tuuli, Korea, asetukset for my locale.
Please have a look at the guide for internationalization. I hope you to enjoy BARAM with Finnish. :-)
In this guide, resource, as part of the expressions resource/locale
is missing a character. Here after corrected along with an illustration:
$ tree -s resources/locale
[ 84] resources/locale
├── [2549] createQmFiles.py
├── [2785] createTsFiles.py
└── [ 906] lang_ko.qm
$ dnf -q rq --installed --archlist noarch,x86_64 --qf '%{name} %{version}' qt* | column
qt6-linguist 6.4.1 qt6-qtdeclarative 6.4.1
qt6-qtbase 6.4.1 qt6-qttools 6.4.1
qt6-qtbase-common 6.4.1 qt6-qttools-common 6.4.1
qt6-qtbase-gui 6.4.1 qt6-qtwayland 6.4.1
$ python3 -m pip show pip pyside6 | grep ^Version | column
Version: 22.3.1 Version: 6.2.4
$ rpm -ql qt6-linguist | grep 'bin\/lupdate'
/usr/bin/lupdate-qt6
/usr/lib64/qt6/bin/lupdate
/usr/lib64/qt6/bin/lupdate-qt6
I would need help to investigate the following error.
[(...)]$ python3.11 -m venv venv && source ./venv/bin/activate
(venv) [(...)]$ cd resources/locale/; touch baram_fi.ts
(venv) [(...)]$ pyside6-luptate view -ts baram_fi.ts
bash: pyside6-luptate: command not found...
You do have a good eye! I've corrected the typo. to resources/locale
.
By the way, every python module that is used by BARAM resides in venv
virtual environment, including QT.
So, pyside6-lupdate
should be in venv
.
And from your command line input, I found that python3.11 -m venv venv
initializes venv
virtual environment.
[(...)]$ python3.11 -m venv venv && source ./venv/bin/activate
So, you should have runpip install -r requirements.txt
to install the packages including PySide6, after above line.
For your information, here is where pyside6-lupdate
is.
[(.../baram)]$ which pyside6-lupdate
which: no pyside6-lupdate in(...)
[(.../baram)]$ source venv/bin/activate
(venv) [(.../baram)]$ which pyside6-lupdate
(...)/baram/venv/bin/pyside6-lupdate
(venv) [(.../baram)]$
Please don't forget to update(git pull) the code from GitHub because it was updated yesterday.
I might need to observe in the detail the syntaxes of the commands composing the instructions. An error occurs with python3.11 -m venv venv
. I investigate here whether that is specific to it by opting for python3.9 -m venv venv
.
[(...)]$ python3.11 -m venv venv && source ./venv/bin/activate
(venv) [(...)]$ pip uninstall -y -r requirements.txt
(venv) [(...)]$ deactivate
[(...)]$ python3.9-m venv venv && source ./venv/bin/activate
(venv) [(...)]$ pip uninstall -y -r requirements.txt
(venv) [(...)]$ pip install -r requirements.txt
Collecting (...)
Using cached (...)
(...)
Requirement already satisfied: wslink>=1.0.4 in ./venv/lib/python3.9/site-packages (from vtk==9.2.2->-r requirements.txt (line 32)) (1.9.1)
Installing collected packages: pytz, six, shiboken6, screeninfo, qasync, PyYAML, pyparsing, psutil, Pillow, numpy, multidict, lxml, kiwisolver, idna, frozenlist, fonttools, filelock, elementpath, cycler, charset-normalizer, attrs, async-timeout, yarl, xmlschema, python-dateutil, PySide6, packaging, h5py, aiosignal, pandas, numexpr, matplotlib, aiohttp, tables, vtk
Successfully installed Pillow-9.3.0 PySide6-6.2.4 PyYAML-6.0 aiohttp-3.8.1 aiosignal-1.2.0 async-timeout-4.0.2 attrs-21.4.0 charset-normalizer-2.1.0 cycler-0.11.0 elementpath-2.5.1 filelock-3.7.1 fonttools-4.34.4 frozenlist-1.3.0 h5py-3.6.0 idna-3.3 kiwisolver-1.4.4 lxml-4.9.1 matplotlib-3.5.2 multidict-6.0.2 numexpr-2.8.3 numpy-1.23.5 packaging-21.3 pandas-1.4.2 psutil-5.9.1 pyparsing-3.0.9 python-dateutil-2.8.2 pytz-2022.1 qasync-0.23.0 screeninfo-0.8 shiboken6-6.2.4 six-1.16.0 tables-3.7.0 vtk-9.2.2 xmlschema-1.10.0 yarl-1.7.2
(venv) [(...)]$ which -a pyside6-lupdate
/home/(...)/baram/venv/bin/pyside6-lupdate
(venv) [(...)]$ touch resources/locale/baram_fi.ts
(venv) [(...)]$ pyside6-lupdate view -ts resources/locale/baram_fi.ts
Scanning directory 'view'...
Error: Parse error at /home/yk/Lataukset/baram/resources/locale/baram_fi.ts:1:0: Premature end of document.
while executing '/home/yk/Lataukset/baram/venv/lib/python3.9/site-packages/PySide6/lupdate view -ts resources/locale/baram_fi.ts'
I encountered that very error message as well with python3.11 -m venv venv
.. Hence we know at least that it is not specific to it.
Now the error message is different!
Previous error was bash: pyside6-luptate: command not found...
.
And now Error: Parse error at /home/yk/Lataukset/baram/resources/locale/baram_fi.ts:1:0: Premature end of document.
Now you have pyside6-lupdate
command as you checked with which
command.
The error of Error: Parse error at...
might be caused by the command touch resources/locale/baram_fi.ts
you typed.
Just delete the file and try pyside6-lupdate view -ts resources/locale/baram_fi.ts
again.
Empty .ts
file may bother pyside6-lupdate
because pyside6-lupdate
tries to update baram_fi.ts
file that was not in correct format(because it's just an empty file in your case).
Once the file baram_fi.ts
is created by pyside6-lupdate
, you can update the file with pyside6-lupdate
command whenever the files in view
folder are changed.
Clearly, I had trouble retaining my lesson. which is obviously observe the instructions.
cd resources/locale/; touch baram_fi.ts
. which brings two causes of error
cd resources/locale/
which causes the message bash: pyside6-luptate: command not found...
touch baram_fi.ts
. which causes the message we are seeing.touch baram_fi.ts
despite my "I might need to observe in the detail the syntaxes of the commands composing the instructions.". So now.
(venv) [(...)]$ pyside6-lupdate view -ts resources/locale/baram_fi.ts
Scanning directory 'view'...
Updating 'resources/locale/baram_fi.ts'...
Found 647 source text(s) (647 new and 0 already existing)
On Wayland, when running pyside6-linguist
as expected the invocation of plug-in xcb has to be done in order to avoid the message Error: Warning: Ignoring WAYLAND_DISPLAY on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
QT Linguist opens successfully. nevertheless once quitting the application this output is produced:
(venv) [(...)]$ QT_QPA_PLATFORM=xcb pyside6-linguist resources/locale/baram_fi.ts
Error: Qt WebEngine seems to be initialized from a plugin. Please set Qt::AA_ShareOpenGLContexts using QCoreApplication::setAttribute and QSGRendererInterface::OpenGLRhi using QQuickWindow::setGraphicsApi before constructing QGuiApplication.
while executing '/home/yk/Lataukset/baram/venv/lib/python3.9/site-packages/PySide6/linguist resources/locale/baram_fi.ts'
That time it seems not to be in my power to avoid that error message.
I tried pyside6-linguist
on Rocky Linux today and saw same message.
The issue seems to be already known to QT guys and safe anyway.
You may have no hurdle to use pyside6-linguist
. Aren't you?
Yes. I remember now that i had early in this report came to notice that the selection of a language conjuncted with the application of the instruction Locale change will be effective from next start presented, had no effect. What could possibly have made me omit mentioning it in the report itself?
Indeed a contribution to translation for a locale makes only sense when a file that is containing the translated strings is aimed to be integrated into the source code. Otherwise of course there would be no motivation to translate without the fulfilment of this condition.
And yet not only the behaviour of this application but also the instructions dedicated to the translation for a locale, which noticeably makes no mention covering an integration of a file containing translation for a locale into this repository, indicate they are not integrated into the source code. But is that so?
I'm sorry for the inconvenience. Applying locale change on the fly was once reviewed but not seemed easy. I will check the possibility of implementation of it again.
And for the integration, the contribution will surely be integrated into the repository, and that's the reason why the source code is hosted on GitHub. I thought that most people using GitHub were familiar with the process of fork and PR(Pull Request). Any part of source code including locale file can be freely forked and modified by anyone and can be integrated in this way. But you are right. I could not think of the people who are not a programmer but just wants to contribute to the translation.
By sharing, and subsequently the spirit involved in sharing your work, you, as any developer sharing while guided by that same spirit, should not find in yourself any reason for being sorry but instead find all reasons for being at the very least quite proud of yourself. Being sorry would likely be on non-technically qualified users' side like i am, since we shall feel frustrated each time our knowledge do not make possible for us to contribute to improve a software or part related to it. I had reason to believe that you might have expected from translators to make use of Pull request as mean of submitting locale files, despite that would be a methodology rather inconvenient for you to deal with.
Thank you for the understanding. I just don't want anyone's time to be wasted. Of course, we need to spend some time to learn anything, but less might be better. I've added a few sentences regarding pull request in internationalization page. Your feedback makes BARAM better and keeps me go further. Thank you very much.
Yes. Your presumptions are all correct.
The first one is the reason why pyside6-luptate
printed following error message when you gave pyside6-luptate
an empty input file with touch
command.
Error: Parse error at /home/yk/Lataukset/baram/resources/locale/baram_fi.ts:1:0: Premature end of document.
The second one is the reason why pyside6-luptate
command has update in its name.
As non-collaborator, i could assume the Git's fork option is left alone as eligible choice of mean for achieving PRs since the Branch option seems to me to be reserved for a person with status collaborator. As per the official instructions you kindly mentioned, i struggled to determine the valid commands against which i would manage changes operated within such fork. Nevertheless that is the practise i am willing to master in order to make the whole task on my own and hence not being cause of extra task on your side.
As you may have noticed, the present platform does not support via its web interface the importation of files whose extensions are ts and py among others. Instead file extension txt is supported which is why the following files were exported with their original extensions manually modified; baram_fi.txt and settings_language.txt.
Wow, you did a good job! I confirmed that the modification worked perfectly though I could not read it. :-) I've applied the modification and pushed it to GitHub. Thank you.
I wish QT Linguist had the ability to reliably review translated strings. I noticed that expressions inside the left-sided panel were not exposed to translation. It may be an omission.
Before closing, some observations:
Common to all pages at nextfoam.github.io
<year><hyphen><year>
, for instance "Copyright © 2017-2022". | Worth noting that an en-dash (–), is what the usage defines for applying to range of dates, not a hyphen (-), which is commonly misused by people. For example, to produce an en-dash within a LibreOffice Writer document; enter "1--1", press space. As a result "--" is converted into an en-dash.Specific to that page
Specific to page and page | "CentOS 8.2 or later" | This formulation gives false hope. CentOS alone, as trademark, cannot have "or later", since the product it covers was officially discontinued by IBM through Red Hat in 2021. Now when it comes to CentOS Stream, it is a separate trademark, whose products it covers are not suitable for use in production environment.
I found that the command in the document has an error.
To process the strings in python files, -extensions py,ui
option should be given.
So, the correct command looks like following.
(venv) [(...)]$ pyside6-lupdate -extensions py,ui view -ts resources/locale/baram_<lang>.ts
I've updated Internationalization page.
As you may expect, pyside6-lupdate
does not remove old strings that were previously taken without the option.
And for the rest of your comments, I've updated the pages. Thank you for those comments.
Yet among those observations, some were also valid in respect to that page. No doubt that you will determine winch ones.
baram v.: 22.0.4
Hello. As it appears in this application GUI, support for locales exits. The relevant file for translation is likely to be one of those located at baram/resources/locale/. Though the present repository and that dedicated site both lack instructions covering the contribution to translations. That would be worth a mention accordingly somewhere.