Hello Jean-Philippe,
Am So., 29. März 2020 um 13:34 Uhr schrieb Jean-Philippe MENGUAL
<jpmengual@debian.org>:
What? Sorry I dont understand.
Someone in your team - I thought you - maintains his own external Git
repo for reviews. That's why I thought the Diff artifacts come from
there.
oh not at all. I dont have any external repo. I wonder wether
Jean-Pierre does, but anyway he does not have the errors I created so I
dont think it has consequences.
really can't do without tracking changes within one single review
loop, then fork a new branch in manpages-l10n and merge the changes
back to master when finished. Or at least, be more careful please when
committing anything. Thanks in advance.
Well I am "happy" to open this topic because I am not confortable with
the situation just now. Here is what I experience, tell me the proper
process. The origin on my problem is I dont know Git enough. Merging
would be a pain for me, so ok to be careful, but then please help me
with a process.
So currently the situation is:
- I start a page (eg. find)
- the loop is long (about 1 month for such page)
- before pushing, git tells me "no, please git pull first"
- pull fails because between the beginning of the loop and now, find was
changed (I guess an automation)
- the situation becomes then completely confusing. Just like I did a few
minutes ago, I have to rm the file, put my copy, add it, and push.
So the problem I identify is that some changes happen while I am working
on the po and I cannot identify them and handle them.
What should I do then which would make sense? I feel merging will be a
pain, so what care process should I use to ensure the commit is good and
dont result failures and side-effects? An idea I am having: should I
push any work once done, even if not reviewed in our loop? I can,
indeed, push any change I do immediately and just mark the commit as
definite or "WIP"? Maybe the fact to commit once the loop is finished is
an error?
Thanks for your help. And sorry for the mess. Git stays a pain for me
but... will learn.
I've just committed the file CONTRIBUTING.md [1]. Well, I assume it
doesn't cover all imagineable questions and problems, but should
explain most of the workflow. Please have a look at it.
Thanks for this document. Some questions reading it:
- is it OK if I consider the translators are only affected from
"Git workflow"? I think this as I guess the first part is automatically
performed by the package maintainers and the translator should not run
any scripts without ensuring it is a good idea.
Yes, the »Git workflow« as described ist the core part. But you can
use any of the helper scripts in po/fr/.
- If I understand the Git workflow, am I right if I say:
"Update a file out of any git repo, somewhere in your local home. Then
git pull, then cp your file, etc"
Yes, it's the safest way in case the review needs some time. In case
of a small change which doesn't need a review, like fixing a typo, you
can edit the file directly in the Git repo, because this ntakes only a
few minutes.
- Before pushing, I need then to run update-po.sh right? I must not just
cp, cehck thintegrigy with msgfmt, then push. I need first to ensure the
push is good via the new steps you mention, all right?
Always run msgfmt -vc on an edited .po file to make sure it is
correct. The script update-po.sh makes additionally sure your .po file
is up-to-date (merged with the latest template) and contains all
changes which happened will you have edited the file externally. After
running the script, you should always have a look again at the file.