On Mon, Aug 28, 2017 at 11:08:52PM +0200, Pavel Sanda wrote: > Scott Kostyshak wrote: > > I think I have a fundamental misunderstanding. I thought that strings > > were supposed to be remerged before asking translators for translations. > > Then the translator returns the po file, and the po and the > > corresponding gmo files are committed. What is the purpose of remerging > > strings before a release? I was spoiled during 2.2.0 because I think > > Georg and Uwe took care of all translation-related issues. That ended up > > being a mistake because I realize that it is important for the release > > manager to know all parts of the process, so I'm trying to learn. > > 1. Whenever new UI string is added or changed this change will propagate into > .po files only via remerging strings. > 2. Whenever new remerge is done *lot* of irrelevant stuff (i.e. source code > lines for string) changes as well - resulting into huge diff. > It gets even worse if different people do remerges because different archs > produce slightly different formatting, resulting into even bigger patch > (didn't check but we can easily talk megabytes per commit here). > > Point 1 implies it is good to remerge strings when you want translators > working on up-to-date UI and if string change occurs (i.e. our minted flame). > Point 2 implies you don't want to do it more often except when really > neccessary because > a) it creates hell when you do detailed seach through commit history via git > log -p
Workaround (which does not negate your point of course since it is a
pain to remember):
git log -p -- . ":(exclude)*.po"
> b) git archive become easily huge just because of such changes
Do frequent commits of .gmo files significantly increase git archive?
> So one has to find certain compromise between 1/2. I would say that when you
> are close to release/string freeze then any string change is worth to remerge
> & commit.
> Also this time it's little easier because you already branched 2.3 so any
> number of remerges won't spoil master history.
> You can test necessity of remerge by checking stats in remerge (number of
> translated/fuzzy/untranslated strings changes for some language which is not
> under extreme care of maintainers who can do remerges of their language only
> - typical case of de,sk,fr?,it?).
> If you don't detect changes in stats, there is no need to remerge&commit for
> realease just to update code lines, because remerge IIRC happens
> automatically inside tarball creation machinery.
> If you finally kick JMarc to give you svn access, regularly updated
> translation status web page might be handy for you.
>
> Ask if you have any question,
Thanks a lot for that detailed explanation. I will be more careful with
this, and am now building up a better understanding.
Scott
signature.asc
Description: PGP signature
