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 b) git archive become easily huge just because of such changes 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, Pavel
