[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: manpages-l10n: please fix file header of xrandr.1.po



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.

Best Regards,
Mario


Reply to: