[Freeipa-devel] [PATCH] 0066 Arrange stripping .po files

[John Dennis]

On 07/23/2012 06:27 AM, Petr Viktorin wrote:
> On 07/20/2012 07:14 PM, John Dennis wrote:
>> On 07/20/2012 12:28 PM, Petr Viktorin wrote:
>>> On 07/20/2012 05:39 PM, John Dennis wrote:
>>>> Great I agree with everything you said.
>>>>
>>>> I'm happy to have the file list be derived from the directory contents.
>>>> Are you planning on doing that in another patch?
>>>
>>> Yes, I want to do it in a new patch.
>>> It's a bit more complicated than it looks: creating a new translation
>>> will work differently than just adding it to LINGUAS and running
>>> create-po. The ticket is for beta 2 so I'd rather not start a new round
>>> of reviews.
>>
>> Fine with me to do that in another patch.
>>
>> As for create-po, I think that's also holdover from pre-Transifex days.
>> With Transifex I'd don't ever see a need to create an empty po file. Do
>> you? Maybe we should just nuke the po creation in the Makefile.
>
> As a translator (for another project), I don't like Transifex and prefer
> to send good old Git pull requests. I understand a "traditional"
> workflow is hard to coordinate with others that use Transifex, but still
> I'd hate it if we became dependent on Tx.
>
> [...]
>>>> But... I do have one final issue/question. I missed this in the first
>>>> review. po_files is now dependent on update-pot instead of the pot file.
>>>> We had decided that we were only going to regenerate the pot file on
>>>> demand at specific times. Won't this dependency change cause the pot
>>>> file to be updated frequently? (I realize only in the local tree). Note
>>>> that when we run the validations we generate a temporary pot file from
>>>> the current contents of the tree specifically to avoid overwriting the
>>>> pot file.
>>>
>>> Are the po files updated more often? I don't really see a reason to
>>> merge the po files with an old pot.
>>
>> What merge are you referring to? The only merge I'm aware of at the
>> moment is during validation, but that merge is done from a temporary
>> updated pot file that is current with the tree.
>
> I'm referring to a manual merge-po.
> po_files are only rebuilt from merge-po, which merges the po files with
> the pot and adds all the missing translations and line numbers. This is
> not needed with Transifex workflow, as Tx should do this internally when
> a pot is pushed to it.
>
>> Any other merging is done by Transifex at the time we pull a po file.
>>
>> The frequency of po update doesn't seem relevant, what is your concern
>> in this regard?
>
> Is there another cause for the po_files to get rebuilt?

Using the TX model there is never a reason to build po files. We just 
pull them from TX.

>
>>>> I suppose having a conversation about when the pot file gets updated is
>>>> a good one to have, we don't do it often enough IMHO. But I'm not sure
>>>> it's correct to modify a file under SCM control if it wasn't
>>>> intentional.
>>>
>>> How is Transifex set up here? If it automatically picks up changes when
>>> the pot file is modified, then we should back up the translations before
>>> changing the pot, so we can't do it automatically.
>>> Another wart is the line number cruft in the pot file -- any time it's
>>> updated we'll get a huge diff, so it makes sense to update sparingly.
>>
>> Transifex gives you two options for your pot file, either you tell TX
>> the location of your pot file in a public SCM and it watches for updates
>> and automatically pulls it when it changes in SCM -or- you manually push
>> the pot file to TX.
>>
>> We've been using the "watch the pot file in git" option. Thus whenever
>> we commit a new version of the pot file all developers and TX get it
>> simultaneously (well sort of).
>>
>> If we do the manual push method the maintainer has to *both* commit to
>> git *and* push to TX, so the former seems less error prone and more
>> automated.
>
> Well, if the pot file is not in the repo, the maintainer only has to
> push it to Tx (after building it of course, but that needs to be done
> anyway).
>
>> The idea was we would have a string freeze prior to release and/or
>> periodic intervals during branch development to update the pot. But we
>> haven't been good about hitting these. However, note a manual push
>> suffers from the same "somebody has to do it at the right moment" problem.
>
> Is this idea documented anywhere? It's hard to do a string freeze if
> it's not enforced automatically, let alone if people don't know there
> should be one.

It was discussed in the developer conference calls.

>
>>> If Transifex is not wired to the pot, we could even go as far as
>>> removing it from SCM entirely -- it's entirely generated, and rebuilding
>>> it takes less than a second.
>>> We'd just have to update Transifex manually.
>>
>> It currently is wired to the pot. You make a valid point about currently
>> not needing to maintain the pot in SCM. When we first set up
>> translations we weren't using TX so having the pot file in SCM was a
>> necessity.
>>
>> Personally I don't trust TX's data storage and I think there is value in
>> having each pot we push to TX be recoverable from our SCM. When things
>> blow up (and they do) it's really nice to be able to reassemble the
>> pieces or at lease follow the trail of how things changed. In the past
>> I've had to answer questions like "How the heck did this string get into
>> this po file?" Such questions can only be answered if we have the pot
>> file we gave the translator. TX doesn't maintain it so we have to (or at
>> least I think there is value in it).
>
> Yes, Transifex only keeps the last pushed pot file.
> However, I don't think the git repo is a good place to store information
> that's missing from Transifex.
>
> To really keep a good history, we'd also need to pull the po files from
> Transifex much more often. I guess we could do that in the main repo,
> but I don't think the other devs would be too happy with daily/weekly
> automated commits reflecting the current state of the translations.
>
> Another option is to keep the history either in a separate branch, or in
> a separate repository (hosted for example on fedorapeople). In that case
> we can include pot snapshots, full po files as they're pulled from Tx,
> or any other info we want, and update it as frequently as needed.
>
>> Perhaps you can read between the lines and detect I don't view TX as the
>> epitome of stability and robustness. It's still young and they are still
>> adding features and changing how it works (kinda like IPA :-)
>   >
>>> Oh, one thing I'll ask about: the Makefile is not automatically rebuilt
>>> when I change Makefile.in, so every time I run an autogen invocation I
>>> found in the main Makefile. Is there an easier way to do this?
>>>
>>
>> Ugh ... autotools :-(
>>
>> The Makefile is generated via configure and I thought autoregen had the
>> smarts to detect the dependencies. I too noticed I had to manually
>> re-run configure. Are we running autoregen? If so and it's not working I
>> don't have an answer, sorry.
>
> install/po/Makefile is generated by this line in the main Makefile:
>
>       cd install; if [ ! -e Makefile ]; then ../autogen.sh --prefix=/usr
> --sysconfdir=/etc --localstatedir=/var --libdir=$(LIBDIR); fi
>
> I'm not very familiar with autotools but I don't think we're using them
> correctly :)

I wouldn't be surprised if we're not using autotools correctly. I'm not 
invested enough in this particular problem to track it down and fix it, 
I've got bigger fish to fry :-)

The only thing holding up the ACK is the question of why po-files now 
has update_pot as a dependency.



-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/