Meeting tonight

[Paul W. Frields]

On Thu, Apr 23, 2009 at 09:06:49AM -0400, John J. McDonough wrote:
> From: "Paul W. Frields" <stickster at 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 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-docs-list/attachments/20090423/152f9a72/attachment.sig>