I can't make tonight's meeting but I'll check out the logs -- I'm interested in hearing how the release notes work went, since I was on vacation and missed most of the fireworks. Well, except the fireworks I saw. Which is a separate story. :-)
Paul
----- Original Message ----- From: "Paul W. Frields" stickster@gmail.com To: "Fedora Documentation Project" fedora-docs-list@redhat.com Sent: Wednesday, April 22, 2009 7:36 PM Subject: Meeting tonight
I'm interested in hearing how the release notes work went, since I was on vacation and missed most of the fireworks.
Well, it really wasn't THAT exciting. After quaid and I beat our heads against the wall for half a day, f13 bailed us out. Then I almost had a heart attack when I couldn't install the koji RPM to test it. But before I pulled out the hari-kari sword, I remembered the new rpm thing, and all went well.
There are a lot of questions to answer, though. In a lot of cases I simply beat it into submission. I would rather the solutions be more elegant. But, I think discretion may be the better part of valor, we'll see.
--McD
On Wed, Apr 22, 2009 at 09:28:07PM -0400, John J. McDonough wrote:
Well, it really wasn't THAT exciting. After quaid and I beat our heads against the wall for half a day, f13 bailed us out. Then I almost had a heart attack when I couldn't install the koji RPM to test it. But before I pulled out the hari-kari sword, I remembered the new rpm thing, and all went well.
There are a lot of questions to answer, though. In a lot of cases I simply beat it into submission. I would rather the solutions be more elegant. But, I think discretion may be the better part of valor, we'll see.
What are some of the remaining questions? How can we improve the process and packaging for the final product?
How would you quantify the remaining risk to the Fedora 11 final release?
----- Original Message ----- From: "Paul W. Frields" stickster@gmail.com To: fedora-docs-list@redhat.com Sent: Thursday, April 23, 2009 8:06 AM Subject: Re: Meeting tonight
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.
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. 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 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 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.
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.
--McD
On Thu, Apr 23, 2009 at 09:06:49AM -0400, John J. McDonough wrote:
From: "Paul W. Frields" stickster@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. ;-)
----- Original Message ----- From: "Paul W. Frields" stickster@gmail.com To: fedora-docs-list@redhat.com Sent: Thursday, April 23, 2009 11:02 AM Subject: Re: Meeting tonight
Yeah, it's not clear to me why that standard was used, or why other usage isn't supported.
It seems to me that we *should* use the ISO, although what I read seemed a little vague, but the issue extends far beyond Docs.
Can you be more specific? I might be able to offer the meager knowledge I have if I know what problems you faced.
Unfortunately, I can't recall the exact cases because they made so little sense, but it seems to me that if I had a de-DE omf file, I would get the release notes in German, but an nl-NL would not. There also seemed to be some inconsistency even within one language, which now that I think back, could have been related to the previous language.
If you look at the screen on nl asking you to rename folders, the target names are in Dutch, but the outside instructions are in English. I'm pretty sure I saw that entire thing in Dutch at least once, but on reflection, I may have been looking at German, since I was running through all the languages we had translated and I could have easily taken German for Dutch without a close look.
On my box, for example, $LANG is set to 'en_US.UTF-8'.
Yes, but what is interesting is that if you log on in German, you get de.UTF-8, but with Dutch, you get en_US.UTF-8. Seems like I may have seen one other language like that. Someone also suggested I explore /etc/sysconfig/i18n, but that seems to always contain en_US no matter what.
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 like that idea, actually. I provided the same behavior as our current; System->Help provides About Fedora and Release notes in yelp, System->About Fedora provides only About Fedora also in yelp. I don't see any obvious way to find the readme's tho. If we put all the Docs on the System->Documentation menu as Publican does it would make more sense to me, but since I didn't understand how those menus get internationalized I didn't want to go there.
One of the reasons for moving to publican was to provide a more rigorous release engineering process
I'm a fan of that reasoning.
In the F12 cycle it won't even be needed because the next release of Transifex
Good thinking. No point in strssing over it.
--McD
On Thu, Apr 23, 2009 at 12:05:35PM -0400, John J. McDonough wrote:
From: "Paul W. Frields" stickster@gmail.com
Yeah, it's not clear to me why that standard was used, or why other usage isn't supported.
It seems to me that we *should* use the ISO, although what I read seemed a little vague, but the issue extends far beyond Docs.
Can you be more specific? I might be able to offer the meager knowledge I have if I know what problems you faced.
Unfortunately, I can't recall the exact cases because they made so little sense, but it seems to me that if I had a de-DE omf file, I would get the release notes in German, but an nl-NL would not. There also seemed to be some inconsistency even within one language, which now that I think back, could have been related to the previous language.
If you look at the screen on nl asking you to rename folders, the target names are in Dutch, but the outside instructions are in English. I'm pretty sure I saw that entire thing in Dutch at least once, but on reflection, I may have been looking at German, since I was running through all the languages we had translated and I could have easily taken German for Dutch without a close look.
It's possible that that's the result of an incomplete 'nl' translation in the code itself. Shouldn't have much to do with the overall locale treatment, I think. All my menus presented as expected.
On my box, for example, $LANG is set to 'en_US.UTF-8'.
Yes, but what is interesting is that if you log on in German, you get de.UTF-8, but with Dutch, you get en_US.UTF-8. Seems like I may have seen one other language like that. Someone also suggested I explore /etc/sysconfig/i18n, but that seems to always contain en_US no matter what.
Hm, my $LANG appeared as 'nl_NL.UTF-8' as expected when I logged in using the procedure I noted previously. The /etc/sysconfig/i18n file, IIRC, just sets the system default.
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 like that idea, actually. I provided the same behavior as our current; System->Help provides About Fedora and Release notes in yelp, System->About Fedora provides only About Fedora also in yelp. I don't see any obvious way to find the readme's tho. If we put all the Docs on the System->Documentation menu as Publican does it would make more sense to me, but since I didn't understand how those menus get internationalized I didn't want to go there.
There were some objections by some people in the Desktop SIG to the About Fedora menu item. They wanted to remove it in favor of some more elegant approach, but I don't remember if they ever spelled that out. Until they do, we should probably go with "least surprise" and leave it there as the one bit of OMF/XML we include. Good catch, and thanks for reminding everyone about it!
John J. McDonough wrote:
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've already done these; but because they will need attention from translators, I haven't checked them in (waiting for Transifex 0.6)
-
John J. McDonough -
Paul W. Frields -
Ruediger Landmann