Open elieserdejesus opened 8 years ago
I commented about lupdate timing https://github.com/elieserdejesus/JamTaba/pull/338#issuecomment-212755850 this is as optional task.
about -locations relative and none I have bat(as shortcut for win) and sh(work on git console) script https://gist.github.com/teamikl/2e633808e674144e805fd0ff21e4560b
It run lupdate with -locations as run linguis with pre/post hook. this make enable preview on linguist and strip those info at terminate.
Very good idea @teamikl , thanks for share the scripts!
About lupdate timing: at moment I will try commit "lupdate" the TS files just before a new release, this work flow work better in my mind. Doublebass and Magnus are working in the translations and Guyava accepted the invitation to work in a Hebrew translation. These 3 guys are not git users, so update the TS files everytime in the github repo is not enough for then, because I need communicate the "time to update translations" using email, or github messages, etc. I prefer centralize these translations tasks in just one moment for everybody, just to preserve my poor mind :)
@elieserdejesus I understand that cost for the extra task. for non-git users it's ok before release timing only.
This is git issue I met, the situation is:
First, I am thinking long running branch, "translate-ja_JP" branch. Because, if it was temporary topic branch, we will have many same branches for every release.
translate-ja_JP branch was branch from master, so it's safe to merge master. but it may have conflict when merge remote branch. now the update *.ts files are remote topic branch. (of cos I can merge remote branch and solve the conflict thought, as work flow it should avoid conflict situation as possible.)
I think this workflow proposal was missing which branch to work on.
the point is which branch .ts file are updated as starting translation task. without update .ts on upstream repo, I met a lot modified: *.ts files by lupdate. I assumed was master that I made branch from.
I know this is for my case only for now. for next release, I will make topic branch from updating-translations-files and merge to my translate-ja_JP branch.
Let's discuss here when found good solution for this. this is a key points summary:
there are two things i wanted to avoid.
another points are
NOTE: the bat/sh script assume *.ts files are already updated on upstream. or the first lupdate will add unfinished/vanished as the result all ts files are marked as modified.
@teamikl
but it may have conflict when merge remote branch. now the update *.ts files are remote topic branch.
Push TS files in a separated branch was the worst idea I had in my life :) The simple solution I can think is: 1 - I will update the TS files and push in master branch. 2 - I will create a new issue "translation tasks" and mention the translators. 3 - You and Jon can create a branch (branching from master now) in your forks, work, push and create a PR or send me a message to pick the commit in your forks.
I prefer the temp branches, even using the same branch name in every release.
@elieserdejesus
1 - I will update the TS files and push in master branch
Ok, this is simple solution. Enough for my case.
what option for lupdate do you use ? to use bat/sh script work as expect, e.g. no-obsolete option must be run upstream side. and I should not add those other options in script. (I will update the gist rev)
@teamikl , the TS files pushed in the translations PR are generated 'manually' with
lupdate -locations none -no-obsolete path/Jamtaba.pro
@elieserdejesus ok, now I removed -no-obsolete option from bat/sh scripts.
1 - I will update the TS files and push in master branch
Ok, this is simple solution. Enough for my case.
it was not just lupdated file into master, updating-translations-files topic branch had resource text changed. my translate-ja_JP branch can safe merge to master but not straight to updating-translations-files. I will make temporary branch for this release translation.
I will make temporary branch for this release translation.
Ok Tea. For the next release we can try a more organized work flow for translation tasks.
@elieserdejesus Yes, It was just a draft. we can improve the process with real issues.
there was another issue for bat/sh scripts it's TS version="2.0" and version="2.1"
after running lupdate on local, version was updated. (en and br files)
our Qt installation or lupdate's version different?
> lupdate -version
lupdate version 5.5.1
our Qt installation or lupdate's version different?
Same version, it's 5.5.1 here too. Maybe the TS version is something like translation versioning? Every time we change the TS file the version number is incremented?
@jonjamcam and @teamikl , Jon fix the word "transmiting" to "transmitting", two letters 't'.
This change will require a update in the TS files. Let's try the translation workflow again, hehe.
I will generate new TS files and push in master branch, ok?
ok.
@elieserdejesus
Maybe the TS version is something like translation versioning? Every time we change the TS file the version number is incremented?
I don't know this. can't find explanation in TS file spec, yet. but at least this increment was for en.ts and pt_BR.ts file only. not all files increment.
I will generate new TS files and push in master branch, ok?
I already fixed the typo and updated my translate-ja_JP
about TS version
Qt/5.5/Src/qttools/src/linguist/shared/ts.cpp was save "2.1" on saveTS and load function ignored the version field.
the issue was es.ts and pt_BR.ts had version "2.0" then when I run the bat/sh script my lupdate will update this value to "2.1"
Expected behavior here was, mark modified only the target locale ts file. I think now is we should use same tools version.
@elieserdejesus Question, when you run lupdate, does it update TS version?
another difference, I have installed Qt 5.5 and 5.6 (using 5.5 for JamTaba) but as I see src code Qt 5.5's lupdate also generate TS version 2.1
Question, when you run lupdate, does it update TS version?
Yes Tea. I manually change the version to 2.0 and after run lupdate the version is changed to 2.1. I changed the version to 2.2 and see the same result, after run lupdate the version is always 2.1. I opened the TS file in QtLinguist and finished all pending translations (just to check if QtLinguist is changing the file version). The version is still 2.1, QtLinguist is not changing the file.
@elieserdejesus Thx, OK so if it was "2.1" the number update will not happen every time.
now en.ts and pt_BR.ts TS version are "2.0" in master, will be "2.1" after translation tasks merged?
now en.ts and pt_BR.ts TS version are "2.0" in master
You right Tea, and I see another problem with the "no input" string translation too. These problems are fixed in master now 6f726e78b147a70ab57c16a29a88f973cdda9e2f.
Translations workflow: