Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Translations scripts improved #17

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Translations scripts improved #17

wants to merge 5 commits into from

Conversation

dhabyx
Copy link
Owner

@dhabyx dhabyx commented Apr 8, 2017

Some fixes for easy translations.

New scripts for generate .po files:

  • translations/Messages.sh: Now is only for update or create new translation files (.po).
  • translations/translation.sh: Now this is the unique script for generate the main .po file. For prevent modifications by new translators.

CMake scripts remake:

  • translations/CMakeLists.txt: It's coming with support for generate .mo files in building phase.

Other files:

  • All .mo files are deleted from repo, those are only created on build time.
  • All Readme files are updated with new features.

This is a remake of translations scripts:
* Messages.sh: Now is only for update or create new translation
    files (.po).
* translation.sh: Now this is the unique script for generate the
    main .po file. For prevent modifications by new translators.
* CMakeLists.txt: It's comming with support for generate .mo
    files in building phase.
* All .mo files are deleted from repo

Signed-off-by: Dhaby Xiloj <[email protected]>
@KonstantinShtepa
Copy link
Collaborator

Hello Dhabyx!
Wow! It was big work! And it seriously getting translation easier.
Is there any reason that you want to merge it using github functional?

@dhabyx
Copy link
Owner Author

dhabyx commented Apr 8, 2017

Only for testing purposes.

If you don't report any problems, we can merge in master branch.

@KonstantinShtepa
Copy link
Collaborator

KonstantinShtepa commented Apr 8, 2017

The overall is very good. 👍
The only thing that confusing me is that now when user would run Messages.sh <lang> it would not update ".pot" file and other translation files if there new lines to translate.
But in first place, about ".pot" file, if there no need in ".pot" file then maybe remove it? And temporary create this file only when it needed(when script is running). Then there would be no need for translation.sh

Also, can you do spanish translation? =)

@dhabyx
Copy link
Owner Author

dhabyx commented Apr 8, 2017

In most cases, the .pot file is created once when developers has added new code, specially with new i18n strings. this file is only the template for the new translations.
The Messages.sh uses the template (.pot) to create or update an .po file, for one language in specific.
The script translations.sh first update all strings on the template (.pot) and then merge changes into each one of .po files; this script should be used only when the project has had new i18n strings.

PD. The Spanish translation it will come soon, but first I am writing an script to install as a package for my distro (Slackware =) )

Signed-off-by: Dhaby Xiloj <[email protected]>
The translation.sh script has updated,
now use --update-all instad of --upgrade-all

Readme has updated with the translation.sh changes
and explains howto use.

Signed-off-by: Dhaby Xiloj <[email protected]>
Signed-off-by: Dhaby Xiloj <[email protected]>
@KonstantinShtepa
Copy link
Collaborator

No, I mean fully delete .pot file. This plasmoid is not so big and .pot file can be builded and removed for every invocation of Message.sh without much hit to any system perfomance.
So there would be just two use of Message.sh with such logic:

  1. ./Message.sh fr
    -> gettext creates .pot file
    -> pot file try to update all existing translations(.po files)
    -> if "fr" translation doesn't exist - copy .pot file to fr.po else delete .pot file
  2. ./Message.sh
    -> gettext creates .pot file
    -> pot file try to update all existing translations(.po files)
    -> pot file deleted

With such logic translators can't get access to .pot file and use it to mess up all other tranlslations.
Maybe better to handle it that way?

P.S. I had idea to add functional of translations install to plasmapkg2. I would try it later, when would have enough free time.

@dhabyx
Copy link
Owner Author

dhabyx commented Apr 10, 2017

Your idea sounds good, the project is very small in terms of size of applications. It's possible that I have organized this scripts according to my experience on medium size applications.
With your scheme, in the future, we can have problems with know what translation is up to date, especially with new versions.
Maintain one single .pot file, for each version, guarantee to us know what translation is correctly updated, and is easy for each translator know if his file is up to date.

@KonstantinShtepa
Copy link
Collaborator

What do you mean by "know if translation is up to date"? The only way to know if translations is up to date is to use some parser over translation files which would tell treir translation status(like the one that used here).
Well it's not like diffrence between these two approaches would have any perceptible impact over translation process. So I'm okay with your approach. There can be talk only when I would write something better.

@dhabyx
Copy link
Owner Author

dhabyx commented Apr 12, 2017

Sorry, my fault, I have not read twice what I wrote in the last comment.

For me it is only to maintain an order, otherwise, in future versions it is possible that we will have problems with knowing if the translations have been properly revised. Taking into account that we will have people who help us in the process of translation into other languages.

This way we could know what translations are up to date, when releasing a new versions; then we can ask for help to people who use this plasmoid.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants