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 <jden...@redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
