Opened 5 years ago
Last modified 3 years ago
#5732 assigned defect
Translation out of sync
Reported by: | Per Östlund | Owned by: | Adeel Asghar |
---|---|---|---|
Priority: | blocker | Milestone: | 1.19.0 |
Component: | OMEdit | Version: | |
Keywords: | Cc: |
Description
The swedish translation files, and probably the other languages too, are out currently out of sync. This causes e.g. different error messages than the ones intended to be displayed. For example this model when instantiated with the NF:
model M Integer n; Real x[:] = {i for i in 1:n}; end M;
gives the error message:
Error: Det första argumentet av 1:n måste vara ett vektoruttryck.
which is the translation for a different error than the error one gets when using english.
Change History (15)
follow-up: 2 comment:1 by , 5 years ago
Component: | *unknown* → OMEdit |
---|---|
Milestone: | Future → 1.16.0 |
Owner: | changed from | to
Status: | new → assigned |
comment:2 by , 5 years ago
Replying to casella:
Following @perost's advice, I think we shold ditch the translations of the command line compiler. I expect nobody using the command line has trouble understanding English error messages.
Regarding the translations in OMEdit, they are probably more useful, we should try to get more active involvement by the community. Any idea how to do that?
One possibility would be to put a message on the splash screen asking if you want to contribute. Of course we then need to make it easy to do, we can't expect people to install OMDev, or possibly even to be familiar with GIT to do that. If we could make it possible via the web interface of GitHub, then the entry barrier would be much lower.
We could add a section in our *Welcome Page* instead of the splash screen.
I must say that updating OMEdit translations is not an easy task for normal users. You need to have Qt installed and should use Qt Linguistic otherwise you will mess up the translation file. We already some instructions on how to do it.
follow-up: 6 comment:3 by , 5 years ago
Whoa, I just had a look at OMEdit_it.ts
. Basically, I understand the reference of each translated message is a source code line. This sounds very fragile, what happens if you just add one line to the .cpp source and all text line numbers are shifted by one?
follow-up: 5 comment:4 by , 5 years ago
Yes but that is not an issue. Qt has a program I don't remember the name perhaps its lrelease
which updates the stuff according to the new source info.
The main thing is how you are going to update the translations in the .ts file. You shouldn't do it manually unless you know 100% what you are using. As I said earlier you need to use Qt Linguist
for adding/updating translations.
comment:5 by , 5 years ago
Replying to adeas31:
The main thing is how you are going to update the translations in the .ts file. You shouldn't do it manually unless you know 100% what you are using. As I said earlier you need to use
Qt Linguist
for adding/updating translations.
OK. I just checked the QT Linguist web page, it claims that
"Translators can use the Qt Linguist tool to translate text in applications. No computer knowledge beyond the ability to start a program and use a text editor or word processor is required."
Can we set up a quick guide whereby a Translator could just do that, and you take care of the rest?
comment:6 by , 5 years ago
The normal procedure for translation is to have a string freeze period before a release, during which no translatable strings in the code are allowed to be changed. The translation files are then generated/updated, after which the translators can begin their work.
In our case we can update the .ts files ourselves, and then the translators only need to run Qt Linguist on the file for their language. Presumably there's only one translator per language, so if necessary we can send and receive the file via mail and let a developer take care of pushing it to git. The import thing is to have a procedure in place, and not just assume that translation happens by itself.
follow-up: 8 comment:7 by , 5 years ago
Is the beta testing period (normally about one month) good for that?
comment:8 by , 5 years ago
Replying to casella:
Is the beta testing period (normally about one month) good for that?
Maybe, though it might be a longer period than needed, a week or two is probably more than enough. Updating the translation usually doesn't take much time, but the translators might of course not have time to do it immediately. Having a long string freeze can be an issue for the developers though, so it's a compromise.
comment:9 by , 5 years ago
"Translators can use the Qt Linguist tool to translate text in applications. No computer knowledge beyond the ability to start a program and use a text editor or word processor is required."
In order to get Qt Linguist
you have to install Qt. And for me installing Qt does require computer knowledge specifically on the platforms other than Windows. I actually tried to look if its possible to just install Qt Linguist
without installing whole Qt framework but unfortunately I didn't find anything.
Can we set up a quick guide whereby a Translator could just do that, and you take care of the rest?
In this regard I agree with Per. We can have a following procedure,
- String freeze period before a release.
- Update the *.ts files so the source code information is synced.
- Translators can update the translations.
One thing to note here is that we don't have dedicated translators. So far it has been a volunteer work.
comment:10 by , 5 years ago
In the very far past, I acted as an OMEdit translator for Italian language. I used Qt Linguist.
Notwithstanding the good capability of Qt Linguist, making good translations is not easy: in most cases a good translation is created only knowing the context in which a given sentence is to be used, and this context is not known to translators through Qt Linguist.
Therefore, to do a good job one should do a tentative translation, wait for a new night build to be created, download and install it, show the result of his/her job in the due context, then fine-tune. I don't expect that many volunteers will do their translations this way.
Therefore translations will often (if not always) be partly confusing or even plain bad. The translations that I made myself are not an exception to this rule.
That's why I recommend my students to use only English as OMEdit language.
However, I understand that this radical approach could create a barrier to use OMEdit, so for some users probably better a bad (or sub-optimal) translation than no translation.
comment:11 by , 5 years ago
Thank you @ceraolo, I think you captured the essence of the story. The world is not black or white, but it's mostly shades of grey :)
Following @perost's advice, I think we shold ditch the translations of the command line compiler. I expect nobody using the command line has trouble understanding English error messages.
Regarding the translations in OMEdit, they are probably more useful, we should try to get more active involvement by the community. Any idea how to do that?
One possibility would be to put a message on the splash screen asking if you want to contribute. Of course we then need to make it easy to do, we can't expect people to install OMDev, or possibly even to be familiar with GIT to do that. If we could make it possible via the web interface of GitHub, then the entry barrier would be much lower.