Thanks @bernardosulzbach. 😄

That blank text box is weird. Maybe it's due to my using an older version of the Qt lupdate program to generate the .ts files, instead of the most recent?

I'll merge this as is, then re-generate the pt_BR strings in the v3.11.x branch using the latest Qt version of lupdate. Lets see if that makes a difference. 😄

Downloading the newest Qt again now. It's going slow, so might be a later on tonight thing (or even tomorrow). 😄

Trying stuff out now. Like yourself, the "Sources and forms" panel isn't working when I try the pt_BR .ts file. This time around I'm using Qt Linguist that comes with Qt 5.12.0.

It's working ok with the de .ts file though.

Not sure how useful that is, but maybe loading the de one for guidance when needed would work?

For some reason the Portuguese translation file lacks source code locations and then linguist doesn't show the widgets or source code quotes. Probably the file was created with this command line:

lupdate -locations none sqlitebrowser.pro

And then lupdate continues respecting how the file was created. I've been able to fix it executing this:

lupdate -locations absolute sqlitebrowser.pro

I've not commited the result, because it is probably better that you do it yourself in your branch, so there are no conflicts later, @bernardosulzbach.

There is an advantage in lacking source code locations: the translation file is then not changing only because the surrounding code has changed. But all the other languages have them, and lacking the context while translating is worse than having trivial changes in the files related to line numbers. I guess you'll prefer to ammend the file.

I've not commited the result, because it is probably better that you do it yourself in your branch, so there are no conflicts later, @bernardosulzbach.

Forget about this, I see now that the pull request is already merged. But I leave it to you nevertheless, unless you want me to commit it.

But all the other languages have them, and lacking the context while translating is worse than having trivial changes in the files related to line numbers.

I agree. In Portuguese and many other languages, we must know how a verb is being used to translate it correctly, so context is even more crucial than for English.

Forget about this, I see now that the pull request is already merged. But I leave it to you nevertheless, unless you want me to commit it.

It would be very kind of you @mgrojo to do it for me.

Of course, no problem. Done.

Best wishes.

lupdate -locations none sqlitebrowser.pro

I think I just ran lupdate src/src.pro, as that's what I wrote on the wiki ages ago:

    https://github.com/sqlitebrowser/sqlitebrowser/wiki/Release-process

Should that be updated to have:

lupdate -locations absolute sqlitebrowser.pro

... instead?

We'll probably need to update all the translation files then, as I updated them all at the same time a while back. So, the problem likely exists in them all. 😦

Reading back, I misunderstood. So it was likely a problem with how the file was created.

Are you able to check if the new Persian language file has the same problem? It was created recently, but I'm not sure what command I used to create it. 😄

Are you able to check if the new Persian language file has the same problem? It was created recently, but I'm not sure what command I used to create it. 😄

The Persian file is OK. The TS files have the problem when they are explicitly created with lupdate -locations none file.pro. The default value for -locations in the creation is absolute (what we want). And then, while updating the file, the default is respecting whatever format the file currently has.

Thanks @mgrojo. 😄