At the moment the i18n of the Falkon (former QupZilla) web browser are done via Transifex.
Is there a way to import that work.
And has somebody time to help to port the translation system in the falkon git to the way KDE does it?
Perhaps I CC'd the wrong i18n people, feel free to remove yourself and hint me to the right ones, thanks!
The usual procedure is:
The first point is easy.
The second one is requires a conversion from the ts format to gettext, and we need to add some code to do the conversion during the compilation, like trojita does, or (avoiding code duplication) negotiate the usage of ECM which will simplifies this step (like gcompris does). It can simplify the life for other things as well and it's not really an heavy dependency.
The last part is a complicated because the qm format does not contain any information about the authorship, which could be relevant for future changes:
https://github.com/QupZilla/qupzilla/tree/master/translations
Maybe the information can be extracted from transifex, but I don't know.
(If I could magically decide, I would even advocate starting the translation from scratch, but I totally understand that this is not really feasible).
I forgot to add: when the non-technical parts are solved, I can implement the required changes.
The second one is requires a conversion from the ts format to gettext, and we need to add some code to do the conversion during the compilation, like trojita does, or (avoiding code duplication) negotiate the usage of ECM which will simplifies this step (like gcompris does). It can simplify the life for other things as well and it's not really an heavy dependency.
We can't use ECM right now, as it uses qmake. However @dfaure offered to port the build system to CMake, so this should be only done after the build system is CMake to not have to write it twice.
Maybe the information can be extracted from transifex, but I don't know.
I'm not sure either, the best I can do is write an announcement to the translation team at Transifex and notify them about the change.
(If I could magically decide, I would even advocate starting the translation from scratch, but I totally understand that this is not really feasible).
I'd like to avoid this if possible. We can ditch some incomplete languages, but I'm sure majority of completed translations are in good shape (there are also KDE translators in various teams).
This is a good to hear. Is this planned before the next release? If so, yes, then we can avoid writing this code twice.
Maybe the information can be extracted from transifex, but I don't know.I'm not sure either, the best I can do is write an announcement to the translation team at Transifex and notify them about the change.
Sure, that would help, but can you please double check if you can extract the history of contributions to each file in Transifex?
If it is possible to do it, I can help with collecting the information for each language, so that we can fill the initial attribution in the gettext files.
(If I could magically decide, I would even advocate starting the translation from scratch, but I totally understand that this is not really feasible).
I'd like to avoid this if possible. We can ditch some incomplete languages, but I'm sure majority of completed translations are in good shape (there are also KDE translators in various teams).
It was more a big "what if" on my side, I understand. We will go through a complicated relicensing in the documentation, so every time I see something without attribution I smell danger.
The CMake buildsystem is done.
Luigi: you can proceed with the translation side of things.
David: please test the cmake buildsystem. If it works for you, I suggest removing the qmake files (no point in maintaining both in parallel, that's recipe for trouble like people forgetting to add files to one or the other, etc.)
It fails here because it doesn't create .qm files from .ts and then can't find them when referenced from .qrc
Normally I would write a patch to make it work, but I'm not entirely sure what's the status with translations.
(Btw.: The qmake build is also broken for me, because it doesn't respect destdir anymore since 31d0e1f6b34845df3184ddc85ccd20649cc27523)
Note Luigi is half away these days (either holiday or work trip), give him a first days to take care of the translation side of things.
Sorry, coming back from a business trip overseas; I will work on this in the next days.
One different though: we can't pack the translations in the qrc files, right now we distribute them in the LC_MESSAGES directory and the generated loader looks for them there.
I've fixed CMake build now and removed all qmake files.
Translations are currently not working, because CMake build system is not compiling the .ts files and plugins still try to look in resources for translations.
What is the correct directory to install translation in? And in what subdirectory should plugins translations go into?
Sorry, I could not work on it yet.
Please remove the reference to translation files from the resource files for now, I will work on it really soon.
No problem.
Please remove the reference to translation files from the resource files for now, I will work on it really soon.
It's done, only thing that is left is code in plugins trying to load translations from qrc at runtime.
For the record, this is the magic trick:
https://api.kde.org/ecm/module/ECMPoQmTools.html
I update the revision, and it should be almost final, but it should not be merged until we solve the problem of the translations.
I checked around a bit on the Transifex interface and I fears that with the Qt source format it's not possible to get the list of authors.
Do you think that it would be useful to just contact the team coordinators and ask them who contributed, when the team is made by more than one person?
I don't think so, coordinator is usually just the first person that joined the translation - eg. that doesn't mean that coordinators keeps track of translation progress or even that they translated anything.
If it is not a big issue, I think just listing all members of translation team as authors is the best that can be done.
If you go to View strings online of a resource and then search for translator it will list just translators that have translated something. For example, mehdioa and I (srazi61) are members of Persian team. But in the following screenshot you just see my username.
@ralavizadeh That isn't really helpful as it will only show name of translator, but not email.
I've tried to ask Transifex if it is possible to extract it somehow, but I didn't receive any response. So I just made an announcement for a translation team, which I hope will get emailed to all translators, and asked them to send me the name and email directly.
To finally resolve this task, let's wait some time to collect the translators info and then import the translations (and ignore the languages for which I did not receive any reply).
I have now extracted all translations with translator credits: https://qupzilla.com/uploads/qupzilla-translations.tar.gz
Translations (*.ts) for application are in root directory, plugin translations are in subdirectories. Names and emails of translators are in translators.txt file.
@ltoscano Is this enough to import them?
Yes, it is. The things that needs to be done are:
I will work on it, using the naming from my pending patch: is it still valid, or are there new/renamed plugins?
One new plugin - src/plugins/VerticalTabs (there are no existing translations from Transifex for this one), nothing else changed.
Quick note while working on it: we don't track the two Spanish variants available (es_MX and es_VE); not sure what the real impact may be, I guess we could load them too; @aacid , any thoughts?
The problem is where to put them, create a new folder just for them? The problem i see with that is that once you've opened the can you can't just say "just for Falkon" or just for es_MX but not for es_AR, which i'm not sure we have the manpower to maintain, what happens when es_AR has a very old translation that is at 5% and "regular" es is at 100%? Sure some words may not be of common use in the _AR variant but you'd really prefer a 100% of not so common words oover a 5% of common words.
Do we know how active those trnslations are and how differnt word-wise are from es?
What's the status of this? I'd like to make a release by the end of this month, would that be possible?
Sorry for the delay. I'm almost done, debugging a charset conversion for uk and fixing some errors in few files that would prevent a push, but I can complete it this evening. I also updated the review which enable the translations, so if you accept it I can push it as well.
@kde-i18n-doc I imported the Falkon translations (see this ticket for more details); the former translators should already know to contact the various localized translation teams, but just in case, check the credits and contact them.
The imported files seems to have some issues. Example (for the ‘nb’ translation):
> msgfmt -c falkon_qt.po falkon_qt.po:6: warning: header field 'Project-Id-Version' missing in header falkon_qt.po:6: warning: header field 'PO-Revision-Date' missing in header falkon_qt.po:6: warning: header field 'Last-Translator' missing in header falkon_qt.po:6: warning: header field 'Language-Team' missing in header falkon_qt.po:6: warning: header field 'Language' missing in header
Non-critical warnings. Any advanced editor (like Lokalize) should be able to add them when you edit the file.