This is really to set up a discussion probably between me and rudi when the
sun comes up for him, but everyone should at least be aware of this problem.
This morning I noticed that zh-CN had reached 100%, but that translation has
been thick with errors for the past few weeks, so I decided to send a note
to trans-list identifying the types of errors. I was later surprised to see
that rudi had pushed the zh-CN to docs.fp.o, surprising since the document
wouldn't build, at least, as of a job that started about an hour before rudi
Anyway, when I looked through the document, I noticed a number of entire
sections that were untranslated. Odd, since Transifex shows it at 100%.
Now I have to admit, I've been happy to see translations complete, and
generally I take a quick peek to see that they look about right, but I
haven't been going through documents in languages I can't read in their
I looked at a couple of other docs on docs.fp.o and some of the same
sections were untranslated. I was about to blame Publican for producing an
incomplete pot (sure, blame it on Publican), but then I found some docs
where those same sections were translated. That leads me to suspect that
something in the interaction between git and Transifex is causing the issue.
As you may or may not be aware, we have been branching liberally to try to
keep the translations straight. I suspect what happened is that some of the
pos were checked out from transifex when we branched, and the old po
overwrote the new po. Normally git would scream bloody murder (and make
your life miserable) if you tried to do this sort of thing, but depending on
how Transifex interacts with git, it might work around this problem.
I'm not sure the best way to correct this. I suspect we need to identify
the problem pos and merge them with the current pot, but I don't know enough
about Transifex to know what this might break.
W dniu 17.11.2009 18:42, Transifex System User pisze:
> po/pl.po | 1305 +++++++++++++++++++++++++++++++--------------------------------
> 1 file changed, 656 insertions(+), 649 deletions(-)
> New commits:
> commit 8070f99d6a7ad8c6419e88260b50d046eb2d66df
> Author: raven<raven(a)fedoraproject.org>
> Date: Tue Nov 17 17:42:19 2009 +0000
> Sending translation for Polish
We did proofreading a bit late because of some random real life
troubles. Could you please re-generate Polish release notes with this
Please go to docs.fedoraproject.org and check your guides to make sure
that they are being displayed properly and that the links are
functioning properly. I know there are a couple of problems but I
need to make sure that we find them all.
Publican (the toolchain that produces these documents) has a tight
structure built around Products (and their logos), Book Titles and Sub
Titles. The elements that are seen in the first mockup are essentially
the "Front Cover" of the book, and IMO are needed in this
circumstance. Changing these elements is also a lot harder than
changing the image that rudi requested, as the tool itself (Publican)
would need to be changed.
That said, i agree with the word "fedora" being used too much
(especially with the non logotype "fedora" that was in my first
So, with some help and guidance from Rudi and Mo, i decided to go with
a simpler text only header to replace the "made with publican" image.
A test book with the new image can be viewed here:
On Tue, Nov 17, 2009 at 4:59 AM, Luya Tshimbalanga
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On 11/16/2009 04:39 AM, Ruediger Landmann wrote:
>> On 11/16/2009 06:18 PM, Luya Tshimbalanga wrote:
>>> Here is illustration the document:
>>> You noticed there are at least four Fedora names on that page alone
>>> which is an overkill
>>> for header.
>> Sorry Luya -- I get a 404 for that URL
>>> I made illustration for suggestion below:
>> And 404 for this one too.
>>> I understand about the ears. As highlighted, there are a lot of repeated
>>> words. I made an alternate version that preserve "Fedora" wordmark
>>> (original color and black version included) for image replacing "Made
>>> with Publican"
>> This isn't bad; but I find the change in colour between the word
>> "Fedora" and the word "Documentation" quite jarring.
>> 404 for this one
> Links fixed.
> - --
> Luya Tshimbalanga
> Graphic & Web Designer
> E: luya(a)fedoraproject.org
> W: http://www.thefinalzone.net
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> -----END PGP SIGNATURE-----
> design-team mailing list
my name is Vedran Miletić and I work as a teaching and research
assistant at Department of informatics, University in Rijeka, Croatia.
I teach lab exercises in Operating systems and auditory exercises in
Computer networks, and in Operating systems we learn how to work in
A the moment, we use "Mandrake Command Line Reference" dating back in
October 2004. Certainly, lots of things remained the same, but some
In order to make a new textbook for our students and new Fedora users
interested in command line in general, I applied to this group.
I see there is already a draft of Command Line Survival Guide at
it covers pretty much what I want. I tried contacting James McElhannon
who was working on it, but the domain of his mail adress is dead.
That being said, I would like to take the work on this and continue
where he left it, if someone is willing to point me how to do it. Hope
we can create something great and useful (and ready in time for Fedora
The new Fedora Wireless Guide includes photographs of different types of
In each case, the manufacturer's logos and/or (obviously) the design of
the hardware itself is visible in the photograph.
1. Are the manufacturer's labels on the hardware and/or the design of
the hardware itself (particularly the styling of the USB adapter in the
first picture) likely to be protected by copyright?
* Is our use of the image to illustrate a generic component of a
particular type likely to be covered by "fair use" for publication in
the United States?
* Is this protection likely to cause problems for people who want to
reuse our content? (I'm thinking in particular of places that have no
"fair use" or equivalent concept in their copyright law, or for reusers
who want to use the image in a completely different context) -- and if
so, do we care, or are reusers on their own here?
2. Could using specific pieces of hardware to illustrate a generic type
of hardware be construed to be an endorsement of this particular piece
of hardware or its manufacturer? If so, do we want to do this in our docs?
Now we have a clear need for attributing source information: thanks to
being relicensed under CC BY SA 3.0 means we can import lots of good
content and so we're likely to do so. Efficient attribution is now
There are two parts to this discussion:
* Technical - how it works in DocBook and Publican
* Brand - how does the Fedora Documentation Project want to attribute
I was going to look at it from a social angle, but I think the brand
angle overrides the social angle. Read on for more.
== Technical proposal ==
To handle copyright attribution, I recommend we adopt this approach:
* For single or a few imports of a chunk of attributable content, use
a <footnote>. Attribution happens on the page it occurs.
Example: Pulling a description of AES encryption from Wikipedia for
the Fedora Security Guide.
* For longer imports, blends, or remixing of content, use
Example: All of the people who work on a guide over the years would
be lists in a standard format under the primary Fedora/Red Hat legal
For the <legalnotice> usage, we would need:
* A standard format for all attributions, to make it fair, clear,
equitable. Alphabetical, for example.
* A change to Publican(?) to look for and use a file,
en-US/Attribution.xml, if it is present. This allows attribution to
be kept within the main document source tree.
== Brand proposal ==
This is a proposal only affecting Fedora-branded works. An upstream,
such as the "Linux Security Guide"
(https://fedorahosted.org/securityguide/), can attribute as it sees
fit, just as a downstream "Red Hat Enteprise Linux Security Guide" can
attribute as it sees fit.
Currently, for some works, we have primary authors in a long list on
the front cover of a work. We've long discussed swapping that for
"Fedora Documentation Project".
Especially as we work with a larger group, the list of authors on the
front cover grows. It visually competes with the Fedora branding.
In other parts of the Fedora Project, we don't see the authors
presented in that fashion. Anaconda is "Anaconda Team
<anaconda-devel(a)redhat.com>". This is more the norm for FLOSS
This is how a "Fedora Docs Team" focus looks in practice:
A good bonus to that would be having either a link to the project page
or text inline that links to the mailing list or project page.
Another idea is to have a notice in the authorship/editorship section,
"For full attribution of contributions to this work, refer to the
One reason for picking a standard is to set the expectation for how we
attribute under the Fedora brand. When we put up individual names, it
creates a competitive space. External content originators that are
remixed may demand front-page attribution. This causes the visual
appeal to diminish while increasing the attribution maintenance.
Having _all_ Fedora-branded guides follow the same standard that puts
the Fedora brand first does the best service to the Fedora Project.
It gives us the least headaches. I think it is the right thing to do.
What do you think?
Karsten 'quaid' Wade, Community Gardener