[RFC] Existing translations and .PO files
by Tommy Reynolds
Hello, Translators!
(I've CC:'ed the F-D-L as well.)
I'm reworking the I18N support in the Fedora Documentation Project
tools, such as the CVS.
Previously, each document has had a set of base DocBook XML files.
As translations were produced, complete new sets of translated XML
files were added to the CVS repository.
Now, we are moving to the more familiar process of archiving only the
original document XML files and the .POT/.PO files needed to produce
the translated XML files using the "xml2po" and "po2xml" tools.
The new make(1) infrastructure will be able to use the .PO files to
create the translated XML files on-the-fly. For example, the files
"en/example-tutorial.xml" and "po/de.po" will be archived but the
derived "de/example-tutorial.xml" file will NOT be archived but will
be considered as a temporary file.
My question is this:
Some FDP documents already have translated versions in CVS. Under
the new process, these archived versions will be discarded in favor
of the on-the-fly translation using .PO files.
Q1) Have you translators kept your .PO files that were used for these
translations?
Q2) If .PO files are not available, is there a way to derive the .PO
files from the translated files or must this be a manual process?
If you have another suggestion to dealing with this, don't be shy; I
may not be asking the right questions.
Cheers
18 years, 2 months
Self-Introduction: Tony Crouch
by Tony Crouch
Hi All,
Am just wanting to introduce myself to this list. I have been a user of
Fedora for a number of years and am keen to get more involved. I am
hoping that through this 'side' of Fedora development I may be able to
lend a hand where possible. Regardless of the task meniality.
Now, to the requested information:
NAME: Tony Crouch
CITY: Moree, New South Wales, Australia
COMPANY: (None) -- Currently Full-Time Mathematics Student.
GOALS FOR FEDORA PROJECT:
I will be the first to admit that I am still much of a fedora novice. I
am now wanting to get serious in expanding and developing my current
knowledge, and I feel the best way to achieve this is to get directly
involved with the project itself.
As mentioned earlier, I am more than happy to take on any tasks assigned
to me, regardless of their meaniality. At this stage, I would probably
feel more comfortable dealing with more the literacy / grammar side of
the documentation. However, I am more than happy to 'spread my wings' in
any direction with regards to the documentation project.
I have not worked for any projects or writing teams previously.
My computer skills are intermediate.
My fingerprint details are as follows:
> [tony@localhost ~]$ gpg --fingerprint 1E28F1A3
> pub 1024D/1E28F1A3 2006-02-13 [expires: 2007-02-13]
> Key fingerprint = 1D37 07EF 3562 E2C0 909C 8D6C D7F1 8A74 1E28 F1A3
> uid Tony Crouch <acrouch2(a)une.edu.au>
> sub 2048g/A0248A4B 2006-02-13 [expires: 2007-02-13]
Cheers,
Tony Crouch
18 years, 2 months
Re: docs-common Makefile.common,1.52,1.53
by Tommy Reynolds
Uttered "Paul W. Frields" (pfrields) <fedora-docs-commits(a)redhat.com>, spake thus:
> Add src-tarball phony target for use when VERSION isn't known externally
When is the version not known?
Cheers
18 years, 2 months
Re: docs-common Makefile.common,1.53,1.54
by Tommy Reynolds
Uttered "Paul W. Frields" (pfrields) <fedora-docs-commits(a)redhat.com>, spake thus:
> Log Message:
> Oops, remember Tommy's rule of good behavior in targets
>
> Index: Makefile.common
> ')' -prune -o -print | cpio -pamdv $(DOCBASE)-$(VERSION)
> - tar -zcvf $@ $(DOCBASE)-$(VERSION)/
> + tar -zcvf $(DOCBASE)-$(VERSION).src.tar.gz $(DOCBASE)-$(VERSION)/
Is that my rule?
Nothing wrong with the original line; I _like_ shorthands like "$@".
The problem is when $*, $@ and the like appear in a template; then
they must be written like this:
define FOO_template
target-${1}:: file.foo
cp $$< $$@
endef
$(foreach F,abc def,$(eval $(call FOO_template,${F})))
That is, you must escape the '$@' in the template because we don't
want it expanded as part of the template expansion, but later when
the target is evaluated.
Cheers
18 years, 2 months
Re: release-notes/en Java-en.xml,1.3,1.4
by Yuan Yijun
2006/2/13, pfrields Paul W. Frields <fedora-docs-commits(a)redhat.com>:
> Author: pfrields
>
> Update of /cvs/docs/release-notes/en
> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv10027/en
>
> Modified Files:
> Java-en.xml
> Log Message:
> More quick and dirty editing
>
>
So wiki is not the only source and translation cannot freeze forever?
There would be hundreds more of fuzzy entries in po now.
--
bbbush ^_^
18 years, 2 months
FC5 test3 release notes tagged
by Karsten Wade
I have tagged the release-notes/ and docs-common/ modules with 'release-
notes-FC-5-test3'.
We can retag anytime today, if heroic translations come in, or other
reasons. We have a standard freeze for the ISO of Midnight UTC today.
Again, translations are *not* expected.
Sorry about the changes in the relnotes making it so late. These
changes are very necessary for us in supporting more translations for
FC5.
- Karsten
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Content Services Fedora Documentation Project
http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject
18 years, 2 months
[ANN] New XInclude standard
by Paul W. Frields
Hi gang,
We have moved to using XIncludes for some specific functions in FDP
docs-common stuff. This was necessitated by a number of issues Karsten
alluded to in a previous email to the list[1]. The pain this should
cause is going to be very minimal, and after you make a few minor
changes to your documents, builds will work again now.
Here are the changes you need to make, only two very small steps:
1. Update to using the DocBook V4.4 DTD. To do this, change your
DOCTYPE declaration at the top of your document to read like this one:
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
<!ENTITY % FEDORA-ENTITIES-EN SYSTEM
"../../docs-common/common/fedora-entities-en.ent">
%FEDORA-ENTITIES-EN;
]>
2. Remove the FDP-INFO entity declaration, and replace its occurrence
in the text (&FDP-INFO;) with the following XML element. Make sure you
self-close the tag, and that you use the proper language for the HREF
attribute.
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
href="fdp-info-en.xml" />
3. Run "make distclean" to clean out cruft.
* * * THAT'S IT! * * *
You can see an example of steps 1 and 2 in a recent commit of mine[2].
Many people have taken to putting funky editor-specific code either at
the top or bottom of a "child" document, to allow proper context editing
(colors, indentation, etc.). If you use an XInclude instead of an
external entity declaration, you should put a DOCTYPE declaration in
every included file -- *exactly* the same as the one shown above in Step
1 -- and your content-aware editor will now work automagically. (Note
that if you do this, you need to declare the root element of your
"child" file, such as "section".)
As always, if you have any questions or comments, reply here please.
Thanks all!
= = =
[1]
http://www.redhat.com/archives/fedora-docs-list/2006-February/msg00082.html
[2]
http://www.redhat.com/archives/fedora-docs-commits/2006-February/msg00255...
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
18 years, 2 months
[ANN] docs-common breakage
by Paul W. Frields
Karsten, Tommy and I are all working on fixes to our docs-common to
accommodate use of (1) XInclude, and (2) translation processes. There
may be significant breakage for the next several days. If you value
your ability to build the docs, don't update your docs-common module.
(Or alternately, you can always "cvs up -D 2006-02-11 docs-common/" to
back out to the previous version, after seeing how badly we've borked
it.)
When we have finished, there may be additional guidelines for existing
and new docs, although we expect the changes for individual modules to
be truly minimal. Or at least that's what we're shooting for.
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
18 years, 2 months
why XInclude for release-notes
by Karsten Wade
<stickster> I am still curious... why did we move to XInclude to start
with?
Here's my small stack of reasons:
i) XIncludes are the XML and modern DB way of doing things, so I wanted
to get them working correctly. So, the technical desire to not use
older, restrictive methods.
This has the advantage of letting us continue to break out XML into
modular files, and have each one a valid XML document. This -should-
make validation, editing, etc. easier for everyone.
ii) Every round of making the relnotes, I was outputting XML from MM and
manually carrying changes over. As the beats and notes grow, this is
crazy.
So, although the XML is rather plain vanilla, if the MM styling is
consistent, at least the formatting is the same
I figured, it would be easier to take the XML from out of MM and stitch
it together with XIncludes than it would be to use entities for the
same.
That said, another post-processing option is to snip the <article> junk
from the files and make the <section>s then pull them in with good ol'
entities.
I suppose that if we can't get the xi to work, we can revert back to
entities for this release.
Also, I'm wondering if this header is properly formed:
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.4//EN"
"http://www.docbook.org/xml/4.4/docbookx.dtd">
Shouldn't there be an 'XML' between 'DocBook' and 'V4.4'?
I took out all the entity calls and added to fdp-info-en.xml a DOCTYPE
declaration and a call to the entities file. I'm continuing to have the
problem of nothing being able to find the DTD from
http://www.docbook.org/xml/4.4/docbookx.dtd . That seems to be just a
problem with me?
I'm going to check all these changes in for now, so that we can work
together to hack through. My error output seems related to the $PWD of
the XIncluded file. I'm working my way through until I probably end up
with just having all the legal notice stuff within the language-specific
areas of the module as a hack-around.
- Karsten
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Content Services Fedora Documentation Project
http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject
18 years, 2 months