On Sun, Oct 16, 2016 at 11:30:41AM +0200, Carsten Schoenert wrote:
> Hi,
> Am 15.10.2016 um 10:54 schrieb Marco Ciampa:
> > Sorry for creating such a mess, but next time please do as you did now: 
> > tell me.
> > I can revert easily this commit and do the fix as you suggested by hand.
> > If you agree I will do this right now so I won't conflict with your work.
> > Hope that you can easily undo the mess on your work after I will commit the 
> > revert...
> no need for that, just go on. As the change to the adoc file was simple
> I "just" need to do some tweaking in between the rebase. But it would be
> even simpler if the one commit was split of into the change to the
> *.adoc files and the changes in the *.po files.
> Than I'd have cherry-picked the change to the adoc file and git would
> drop that patch again while rebasing automatically. So I was needed to a
> fake change and rebuild the de.po file to get a fast forward rebase.


> The workflow for the work on the documentation should be going easier in
> the future.
> > After this I will write you to suggest a tool that could help you resolve
> > these conflict more easily...
> I know those tools, but I'm not very similar with them

what do you mean with similar?

> and I'd like to
> use a more straight forward way based on a typical git workflow. 

actually using a specialized merge for .po files is exactly what a git
workflow was meant to...

> But
> this brings me back to the previous discussion about my small changes
> within a adoc file some days ago. They will always be around!
> https://github.com/KiCad/kicad-doc/pull/420

probably, I am afraid that that will happen again until the specialized
po-merge tool will be used by all doc commiters 

> Now is was exactly happen what I was trying to prevent by writing about
> such problems on one of my previous pull request. I still believe the
> current workflow in kicad-doc is wrong as your useful change is in deep

I do not say that you are wrong. I just wanted to say that I do not agree
but perhaps it is just me not having grasped totally the whole matter.

I am still thinking about a way to improve this whole workflow for all
contributors but I am afraid that the github interface, for the .po files
it (un-)handle, can get in the way instead of making our life easier...

> technically nothing other than my suggested changes on the PR. It's not
> possible that the few people with commit access on GitHub can nurse all
> the languages! The key is to create a team of people that carry on the
> their specific language.

Mmm actually I do not see how to avoid it ...

> And in my eyes it's better not to try to keep all languages actual but
> focus on the master content. 

I agree with you that perfectioning the master document _before_ starting
any translation effort would bring an overall improvement in all the
translation progress but I see that there are still many errors and
simply wrong or improvable areas (screenshots for example) in the
"stable" document branch that I am afraid it remains a "TO DO" thing for

Simply put, there are too few native english speakers able to review the
master document before we can publish it as "stable". We do not have 
even just reviewers for correctness of the workflow and correctness and /
or update of the screenshots ...

> Let locales do there job they can do best.

I am afraid that locales cannot and should not improve their copy if the
master is wrong...

> I'm still thinking about to step down my work on the translation as it's
> currently not really fun to work on the stuff.
> I'm (co)maintaining a few Debian packages and that's the main focus for me.

Ok I agree again with you: having a working KiCad is more important than
it's manual translation...

> The only strong reason
> to not step down is to keep KiCad in Debian in a good shape as I really
> want to thank KiCad to be serious alternative for Eagle and Fritzung.

This conflict with last statement. You want to step down translating or
step down mantaining Debian packages? I may say that Debian packaging is

> BTW: Any special reason to not communicate through the mailing list?

Wrong default on the mailing list reply-to settings? Oooops! Fixed it now!


Marco Ciampa

I know a joke about UDP, but you might not get it.


 GNU/Linux User #78271
 FSFE fellow #364


Mailing list: https://launchpad.net/~kicad-doc-devs
Post to     : kicad-doc-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-doc-devs
More help   : https://help.launchpad.net/ListHelp

Reply via email to