On 08/30/2017 04:32 AM, Scott Kostyshak wrote: > 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"
# git config alias.lognopo "log -p -- . ':(exclude)*.po'" # git lognopo Richard
