kicad-doc-devs team mailing list archive

[Carsten Schoenert <c.schoenert@xxxxxxxxxxx>]

I was on some business trips and also on some free days of work, so I
answer with some days of delay.

On 17.10.2016 10:19, Marco Ciampa wrote:
[...]
>>> 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?

I mean familiar.

>> 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...

You wrote "specialized", and that's a thing I want to avoid. If you need
some special thing or tool to work on the documentation files than
obviously is something broken by the workflow.
As tried written above, I'm not knowing these special tools well enough
and I though other contributors also don't if I look on the last changes.

If the commits would be more granular and split of into the right parts
it would be nothing more than cherry-picking. But the decision if a pull
request is taken is up to the people with access right.
I personally don't like that GitHub WebUI workflow that much as I can't
fix small issues by this. Maybe I'm old school, I like patches via email.

And especially for l10n or i18n work there are possibilities to work via
webui by contributors. I haven't tested that by myself how to integrate
such a workflow e.g for KiCad. Other projects have done this already so
no need to reinvent a wheel.
On the FOSDEM I was able to talk with Michal Cihar, the creator of
Weblate. He is providing free hosting for FOSS projects.

https://weblate.org/

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

That wont happen I believe, or you will need to do the entire
translation work on your own.

>> 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...

It would be easier if a desired workflow and priorities would would be
more clear.
I don't see much difference right now between the master and the 4.0
branch, but they differ that much so cherry-picking for trivial changes
aren't possible. The documentation hasn't evolved much in the last year
that justifies this situation.
That's extremely demotivating for getting things done. And on top of
that if I'm doing some (yes only) cleaning up work inside of the *.adoc
files in the master branch I hear only "Oh no we can't do that, it's
breaking languages." I don't see a community that is working on the
documentation like happen in the KiCad development.

>> 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 ...

Than you have completely don't understand what I want to say. Take a
look around and see how Thunderbird is localized. All languages are done
by volunteers and they are responsible for their language. If they
haven't time to translate string until the next release they are of
course broken and are going not to be available translated.

>> 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
> us.

What's about to start here? My English isn't of course not that like
native speakers. But to wait until one of the native English people will
take care is taking time and will solve nothing.

> 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 ...

But you/we can improve the "master" by suggestions and collecting what
needs to be improved or expanded. As long as we discuss if a line break
is breaking files ... I'm not motivated to do so.

>> 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...

That's partially correct, but OTOH we do so! So something is working
wrong here.
As previously written, the stable branch has to be stable. The master
branch is the current development branch.

While reworking the Eeschema manual I have seen a lot of at least small
issues in the original english text, but currently I'm not in the mood
to prepare here something after my last experiences. And if possible I
was was working around some things already in the German translation.
For example the Alternative Text for the images.

>> 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
> paramount...

Definitely in working less on the translations of KiCad if they take to
much times. In my (co)maintaining work for Debian I can pick and decide
what current upstream changes are worthy to put into packages.

-- 
Regards
Carsten Schoenert