On Thu, Apr 23, 2009 at 09:06:49AM -0400, John J. McDonough wrote:
From: "Paul W. Frields" <stickster(a)gmail.com>
> What are some of the remaining questions?
I guess the biggie, IMO, is whether we are going to use ISO Language/Loc
codes and how we are going to apply them. The standard says you don't
need the loc code unless it makes sense, but Publican seems to like it
always. Also, ISO says hyphen between lang and loc, Publican uses a
hyphen, most places in Fedora it is an underscore.
Yeah, it's not clear to me why that standard was used, or why other
usage isn't supported. Whether it matches other Fedora usage or not
probably isn't as important, as long as (1) the toolchain used for
translation is working, and (2) the operating environment consistently
selects the right files given whatever locale is set for the user.
ISO codes work sometimes, but in preview, I made .omf's for both
and the old code because I couldn't fathom the pattern as to why some
things worked sometimes and not others, so I beat it with a club.
Can you be more specific? I might be able to offer the meager
knowledge I have if I know what problems you faced.
Once we get some breathing space I need to learn how the language
gets from the button on the logon screen to yelp. Perhaps then the
behavior would make sense. Actually, I think Docs aren't the only
thing broken. For example, log on with Dutch and LANG gets set to
en_US, and the screen that asks if you want to rename folders
sometimes comes up in Dutch and sometimes in English.
The $LANG environment variable is used as the fallback for all locale
environment variables in bash not otherwise set (usually those envars
start with $LC). On my box, for example, $LANG is set to
When I select "Nederlander (Nederland)," which I believe is Dutch,
from the locale menu at login, I get the expected behavior. The menus
appear in Dutch, and I get a prompt asking for renaming folders. If I
exit the session and don't change the defaults from English, the next
login reverts to US English the same way.
The other thing is the omf's. As far as I can tell, Publican
way to make them, and apart from a fully set up f-d-u, the only way I
could come up with them was brute force. Again, once we get breathing
space we need to come up with a strategy.
I would argue that we don't need to package OMFs or XML if we're
providing the standard HTML-version builds from Publican. I provided
them before as what I thought was a more "standard" way of including
documentation, that being through the online Help menu.
However, including menu items directly is a fine way as well, and I
would say if those menu items do an "xdg-open" on the HTML, then
there's really no reason to provide OMFs or XML backing them up.
I didn't convert the 5 "minor" docs to Publican. We
should go ahead and
do that since they now look a little like orphans.
I also wonder a little about the value of running Publican within
rpmbuild. I guess I flip flop on that a little On the one hand, the real
sources are in the rpm, and that is a good thing. On the other, the
rpmbuild takes a very long time, and the help xmls look awfully similar to
the originals anyway. I guess it does force a clean build, which is
probably a very good thing. Maybe the msgmerge should also be in
rpmbuild. It isn't right now.
One of the reasons for moving to publican was to provide a more
rigorous release engineering process where the docs are built from
source inside the build system in the same fashion as other code-type
content. I think that's a rational way of doing things.
When you say msgmerge, you mean breaking the single POTs apart into
separates? I think this is really a manual work around that we don't
want to spend time on doing in rpmbuild. In the F12 cycle it won't
even be needed because the next release of Transifex, 0.6, will
directly support multi-POT repositories like Publican.
> How would you quantify the remaining risk to the
> Fedora 11 final release?
I think the biggest question mark is how many translations get done.
There are a few minor updates that have been mentioned since we froze back
on 4/1, but the main issue we dealt with for preview was simply getting
the srpm onto Koji. We need a few more packagers in Docs I guess. But my
Tuesday activities were pretty rote; update the dates in the readmes and
run f-d-u, grab the latest translations and run msgmerge, then run
rpmbuild. Then run around finding someone to push it to Koji. That was
the hardest part and it shouldn't have been. I guess the Publican part
and msgmerge went smoothly partly because laubersm has been policing the
translations very carefully. That risk completely got by me and if she
hadn't been on top of it I may have had a much more difficult time.
Teamwork ftw! Now that I'm back I'm happy to help with fixes,
education, unnecessary opinions, or whatever anyone might want from
Paul W. Frields http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
- - - - http://pfrields.fedorapeople.org/
: stickster @ #fedora-docs, #fedora-devel, #fredlug