On Thu, Apr 23, 2009 at 09:06:49AM -0400, John J. McDonough wrote: > From: "Paul W. Frields" <stickster@xxxxxxxxx> >> 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 the ISO > 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 'en_US.UTF-8'. 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 provides no > 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 me. ;-) -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
Attachment:
pgpvQuSx6IVCG.pgp
Description: PGP signature
-- fedora-docs-list mailing list fedora-docs-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-docs-list
