Generating multilingual PDF files out of GNOME documentation
Robert describes how to generate PDF files from GNOME documentation source files.
We describe here how to manually generate PDF files from translated documentation.
The relevant gnome-doc-utils files for documentation generation is at http://git.gnome.org/cgit/gnome-doc-utils/tree/tools. As far as I understand from reading the makefile, there is no support yet to build PDFs out of localised documentation.
Let’s assume we want to generate PDF documentation for the GNOME 2 User Guide, for the Greek language.
1. We clone the relevant repository
$ git clone git://git.gnome.org/gnome-user-docs
2. Then,
cd gnome-user-docs/gnome2-user-guide/
and now generate the equivalent XML files found in C/ with the localisation for the Greek language (found in el/),
\ls C/*.xml | perl -n -e 'chop; $a=$_; print "xml2po -p el/el.po $a > el/`basename $a`\n"' | sh
3. Let’s see what we created,
$ ls el/ el.po glossary.xml goscustdesk.xml gosfeedback.xml gosoverview.xml gosstartsession.xml legal.xml figures gosbasic.xml goseditmainmenu.xml gosnautilus.xml gospanel.xml gostools.xml user-guide.xml $ _
The main file is user-guide.xml, which references the rest of the XML files.
4. One additional step I like to do is convert all those individual .xml in a single big XML file just before performing the conversion to PDF. This helps to figure out any markup mistakes that could have been caused during the translation.
cd el/
xmllint --noent user-guide.xml --output documentation-user-guide.xml
This step does not have the desired effect with the XML in the user-guide because the include files are referenced with “<include xmlns=”http://www.w3.org/2001/XInclude” href=”gosbasic.xml”/>” rather than the “&gosbasic;” which “xmllint –noent” appears to like. Other GNOME documentation use the latter style. Lazyweb, any tips so that xmllint can create a single big fat XML file?
4. You may want to manually populate the figures/ directory. That is, copy any C/figures/* files that are not present in your LL/figures/ directory.
5. In order to create PDF files in NON-iso-8859-1, we need to use the xetex backend,
dblatex --backend=xetex --verbose documentation-user-guide.xml
If all go well, you are greeted with a documentation-user-guide.pdf document.
Two things may go wrong here; there is either an invalid construct in the XML file or you have stumbled on a XeTex bug for your language.
For the Greek language there is a known bug and a workaround for XeTex.
Here is the GNOME2 User Guide (PDF) for
I also tried the user-guide with
Chinese: Fails to compile, encoding problem or most probably limitation in XeTeX.
Thai: Compiles just fine but no Thai font is available. How do you add fonts to XeTeX?
Punjabi: Compiles just fine but no Hindi font is available. How do you add fonts to XeTeX?
Playing with Git
Git is a version control system (VCS) software that is used for source code management (SCM). There are several examples of VCS software, such as CVS and SVN. What makes Git different is that it is a distributed VCS, that is, a DVCS.
Being a DVCS, when you use Git you create fully capable local repositories that can be used for offline work. When you get the files of a repository, you actually grab the full information (this makes the initial creation of local repositories out of a remote repository slower, and the repositories are bigger).
You can install git by installing the git package. You can test it by opening a terminal window, and running
git clone git://github.com/schacon/whygitisbetter.git
The files appear in a directory called whygitisbetter. In a subdirectory called .git/,git stores all the controlling information it requires to manage the local repository. When you enter the repository directory (whygitisbetter in our case), you can issue commands that will figure out what’s going on because of the info in .git/.
With git, we create local copies of repositories by cloning. If you have used CVS or SVN, this is somewhat equivalent to the checkout command. By cloning, you create a full local repository. When you checkout with CVS or SVN, you get the latest snapshot only of the source code.
What you downloaded above is the source code for the http://www.whygitisbetterthanx.com/ website. It describes the relative advantages of git compared to other VCS and DVCS systems.
Among the different sources of documentation for git, I think one of the easiest to read is the Git Community Book. It is consise and easy to follow, and it comes with video casting (videos that show different tasks, with audio guidance).
You can create local repositories on your system. If you want to have a remote repository, you can create an account at GitHub, an attractive start-up that offers 100MB free space for your git repository. Therefore, you can host your pet project on github quite easily.
GitHub combines source code management with social networking, no matter how strange that may look like. It comes with tools that allows to maintain your own copies of repositories (for example, from other github users), and helps with the communication. For example, if I create my own copy of the whygitisbetter repository and add something nice to the book, I can send a pull request (with the click of a button) to the maintainer to grab my changes!
If you have already used another SCM tool (non-distributed), it takes some time to get used to the new way of git. It is a good skill to have, and the effort should pay off quickly. There is a SVN to Git crash course available.
If you have never used an SCM, it is cool to go for git. There is nothing to unlearn, and you will get a new skill.
Git is used for the developement of the Linux kernel, the Perl language, Ruby On Rails, and others.
Help make «DocBook XML to PDF» work for Greek
<?xml version=”1.0″ encoding=”utf-8″?>
<!DOCTYPE article PUBLIC “-//OASIS//DTD DocBook XML V4.2//EN”
“http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd”>
<article lang=”en”>
<section><title>Title</title>
<para>ëãáâṩẫëĝéõōåőȩçą</para>
<para>ЁЂыњѨѬѺѸѶѦщЖЊЌЍШЩзф</para>
<para>ᾶᾳὰέᾁᾂδϕϟϸϡϸϸαϷϕϲδϕϛ€ϕ©ϖϐͻ©ϖϐ</para>
</section>
</article>
This is an issue that I would appreciate if someone could help in solving.
The above document (mytestfile.xml) is a DocBook XML document with text in many scripts (latin, cyrillic and greek). Normally it was difficult to convert to PDF, until recently.
Now, one can run
dblatex --backend=xetex --verbose mytestfile.xml
(requires to install the dblatex package and any dependencies) and it creates mytestfile.pdf. If you have a fresh installation of Ubuntu 8.10 and you go through the process of installing these packages, please make a list of them, to use as advice for new users.
Since we use XeTeX as a backend, we can work with Unicode text directly, which is the proper thing to do. Above you can see that all characters are shown (except a few obscure ones that are not found in DejaVu Sans and are shown as boxes). You can see Latin (+Extended), Cyrillic (+Extended), Greek (+Extended) in the same document.
The issue arises when we change the lang modifier in the document above, from en to el. Here you see Τιτλε, which in fact is Title but with the characters replaced with their Greek equivalent. This is a sign for non-Unicode, 8-bit encoding conversion issue. In addition, some of the rest of the characters are shown, and apparently a strange conversion took place.
What we need to do is figure out is how to fix xetex when ‘lang=el’. There is some work to get Greek XeTeX support upstream, and there are instructions on how to add local Greek XeTeX support in your distribution.
What we need is instructions on how to fix the Greek XeTeX support in Ubuntu 8.10, and test that dblatex can generate documents correctly when lang=el.
For your testing, here are the files mytestfile-en.pdf, mytestfile-el.pdf, mytestfile-en.xml, mytestfile-el.xml.
Code of conduct και ελληνικές κοινότητες ΕΛ/ΛΑΚ
Ένα πρόβλημα με τις κοινότητες ελ/λακ είναι ότι μερικά από τα μέλη δεν ακολουθούν τους τυπικούς κανόνες συμπεριφοράς, και αυτό έχει το αποτέλεσμα να δημιουργείται συχνά ένα αρνητικό κλίμα.
Ένα πρόσφατο παράδειγμα είναι στη λίστα gnome-i18n, όπου ένας νέος μεταφραστής ήταν πολύ αρνητικός και προσβλητικός στη συμπεριφορά του απέναντι στο συντονιστή της συγκεκριμένης γλώσσας και άλλα άτομα που έλαβαν μέρος στη συζήτηση (=όπως εμένα!). Κατά τη συζήτηση, έγινε αναφορά στο λεγόμενο Code of conduct του GNOME, απλοί κανόνες καλής συμπεριφοράς. Αν θέλεις να συμμετέχεις στο GNOME, πρέπει να ακολουθείς τους κανόνες καλής συμπεριφοράς. Εννοείται ότι ο καθένας που λαμβαίνει μέρος στην ανάπτυξη του GNOME ακολουθεί τους κανόνες αυτούς· ωστόσο μπορεί κάποιος και να υπογράψει ότι ακολουθεί τους κανόνες. Το ίδιο συμβαίνει με την κοινότητα του Ubuntu Linux όπου ο χρήστης μπορεί να υπογράψει ψηφιακά το Code of Conduct με το κλειδί του, και να λάβει το χαρακτηρισμό Ubuntero.
Στην ελληνική πραγματικότητα δεν έχουμε φτάσει ακόμα σε τέτοια επίπεδα και η κατάσταση είναι σχεδόν ad-hoc. Αναφερθήκαμε πρόσφατα στο πρόβλημα με το φόρουμ Linux του Adslgr.com.Ένα πράγμα που θεωρώ πολύ σημαντικό είναι ότι πρέπει να υπάρχει σεβασμός και τήρηση των τυπικών κανόνων καλής συμπεριφοράς. Παλαιότερα που έβλεπα τη λίστα LGU, παρατηρούσα ότι υπήρχαν συχνές «παραβάσεις», με αποτέλεσμα να επικρατεί αρνητικό κλίμα, να μην βγαίνουν αποτελέσματα στις συζητήσεις, ο καθένας να προσπαθεί να κάνει τον έξυπνο και να «την βγει» στον άλλο, και ουσιαστικά να γίνεται κακό στην κοινότητα, στους νέους χρήστες. Για τώρα δεν γνωρίζω, έχω την εντύπωση ότι τα πράγματα δεν έχουν καλυτερέψει σημαντικά. Είδα την πρόσφατη συζήτηση στην LGU για το σχολιασμό της μετάφρασης από ΕΛΟΤ των θεμελιωδών όρων πληροφορικής. Πολλά άτομα απάντησαν, ωστόσο στη συζήτηση αυτή δεν παρατήρησα κάποιο χειροπιαστό αποτέλεσμα.
Ένα άλλο πρόσφατο παράδειγμα είναι με αυτό το γράμμα στη λίστα public@hellug.gr. Ανεξάρτητα αν έχει δίκιο ή όχι ο αποστολέας, το γράμμα αυτό είναι από τα πιο τυπικά για να κάνει μια συζήτηση να αποσυντονιστεί. Ο δε αποστολέας του γράμματος δεν είναι νέος χρήστης· είναι μέλος της κοινότητας πάνω από δέκα χρόνια. Αντί να έχει την ωριμότητα να κλείσει το θέμα, το ανοίγει περισσότερο.
Βλέπω αυτό το εχθρικό περιβάλλον να διαιωνίζεται σε συγκεκριμένες κοινότητες, με μικρές ελπίδες για αλλαγή.
Προσωπικά αφιερώνω χρόνο στο φόρουμ του ελληνικού Ubuntu, στο http://ubuntu.opengr.net/ όπου υπάρχει έντονη προσπάθεια να έχουμε ένα θετικό περιβάλλον. Βλέπουμε να έχουμε αποτελέσματα, και να γίνονται μέλη περισσότεροι νέοι χρήστες της διανομής. Το ίδιο θετικό περιβάλλον υπάρχει στη λίστα του Ubuntu-gr.
Αντιγράφω εδώ τους κανόνες καλής συμπεριφοράς του GNOME,
Advice
- Be respectful and considerate:
- Disagreement is no excuse for poor behaviour or personal attacks. Remember that a community where people feel uncomfortable is not a productive one.
- Be patient and generous:
- If someone asks for help it is because they need it. Do politely suggest specific documentation or more appropriate venues where appropriate, but avoid aggressive or vague responses such as “RTFM”.
- Assume people mean well:
- Remember that decisions are often a difficult choice between competing priorities. If you disagree, please do so politely.
- If something seems outrageous, check that you did not misinterpret it. Ask for clarification, but do not assume the worst.
- Try to be concise:
- Avoid repeating what has been said already. Making a conversation larger makes it difficult to follow, and people often feel personally attacked if they receive multiple messages telling them the same thing.
ANTLR grammar for XKB, and Relax NG schema (draft)
I completed the ANTLRv3 grammar for symbols/ configuration files of XKB. The grammar can parse and create the abstract syntax tree (AST) for all keyboard layouts in xkeyboard-config.
ANTLRv3 helps you create parsers for domain specific languages (DSL), an example of which is the configuration files in XKB.
Having the ANTLRv3 grammar for a configuration file allows to generate code in any of the supported target lagnuages (C, C++, Java, Python, C#, etc), so that you easily include a parser that reads those files. Essentially you avoid using custom parsers which can be difficult to maintain, or parsers that were generated with flex/bison.
On a similar note, here is the grammar to parse Compose files (such as en_US.UTF-8/Compose.pre). I am not going to be using in the project for now, but it was fun writing it. The Python target takes 18s to create the AST for the >5500 lines of the en_US.UTF-8 compose file, on a typical modern laptop.
I am also working on creating a RelaxNG schema for the XKB configuration files (those under symbols/). There is a draft available, which needs much more work.The Relax NG book by Eric van de Vlist is very useful here.
The immediate goal is to use the code generated by ANTLR to parse the XKB files and create XML files based on the Relax NG schema. I am using Python, and there are a few options; the libxml2 bindings for Python, and PyXML. The latter has more visible documentation, but I think that I should better be using the former.
Update: lxml appears to be the nice way to use libxml2 (instead of using directly libxml2).
OpenOffice Writer training notes (request: make training video plz!)
OpenOffice.org is one of the most important layers of the open-source stack. Although it does a superb job, we really need to make effort to get more users working on it.
Here we present training notes for the use of Writer, the word processor component of OpenOffice.org. We aim to make the best use of styles by creating well-structured documents. What we show here is built on work of others, including the OpenOffice Linux.com articles by Bruce Byfield, the amazing OpenOffice.org documentation and the spot-on article of Christian Paratschek at osnews.com. Actually, the following follow more or less Christian’s article.
When training in OpenOffice.org, it is important to create a fluid workflow that starts from the basics and increases gradually in complexity. It would be great if someone could turn the notes in a training video.
- We start of with running OpenOffice.org Writer. The default windows appears. Compared with other word processors, in OOo we see this text boundary in the document (the dim rectangle that shows the area we can write in). We mention we can show/hide it with View/Text boundaries.
- When creating a document, it is good to set the properties such as Title and Subject. We do that from File/Properties/Description. It may look too much effort now, but it will help us later wherever we want to write the document title or subject. Use Using OpenOffice.org Writer for title and How to write nice document in OpenOffice.org Writer for subject.
- Writer supports styles which makes life much easier. You probably have used styles before; using Heading 1, Heading 2 for headings so that you can create easily the Table of Contents. Writer has a Styles and Formatting window that is accessible from the icon/button near the File menu. The icon looks like a hand clicking on a 3×3 grid. You can also get the windows from Format/Styles and Formatting, or by simply pressing F11. Once you do that, you get a floating window. You can dock it by dragging it to the right edge of the Writer window. If you are into 3D desktop, it may not be easy to dock (it automatically switches to another side of the desktop cube). In this case, use the key combination Ctrl-Shift-F10 to dock the Styles and Formatting window. It is good here to resize the document (that is, change the magnification) so that it appears centered with little empty space around.
- Writer supports styles, not only for Paragraphs (like Heading 1) but also for Pages. See the status bar at the bottom of the Writer window; it mentions Default which is the default page style. When we write a document, the first page is good to have a distinct style that is appropriate to the properties of a first page. This includes, making sure the second page appears empty, the page gets no page numbering and so on. On the Styles and Formating dock we select the Page styles tab and we double-click on the First Page style. This will set the current page to the First Page style, and we can verify visually by looking at the status bar (Now First Page instead of the old Default).
- We are not writing yet; lets create the subsequent pages first. To do so, we insert manual breaks in our document. Click on Insent/Manual Break…/ and select to insert a Page Break. As style for the page after the break choose the Index page style, tick on Change page number, and make sure the numbering starts from 1. Click OK. Proper documents start numbering from the Index page. The Index page is the page we put the Table of Contents, Table of Figures and so on.
- Make sure the cursor is on the new page with the Index style. We need to create a new page break, so that we can get writing the actual document. Click on Insert/Manual Break…/ and select a Page Break. As style for the page after the break you can choose Default. Leave any page numbering settings as is because it inherits from before. Click OK.
- Now, to view what we have achieved, let’s go to Print Preview, and choose to see four pages at a time. We can see the first page, another page which is intentionally left blank, the Index page and the Default page. Close Print preview and return to the document.
- Now let’s go back to the first page. We want to put the title on the first page. Nothing extravagant, at least yet. What we do is we visit the Paragraph styles and find the Title style. While the cursor is on the first page at the start, we double-click on the Title style. The cursor moves the the center of the document and we can verify that the Title paragraph style has been applied; see on the right of the Styles and Formating icon on the top-left of the Writer window. Shall we write the title of the document now? Not so fast. We can insert the title as a field, because we already wrote it in the properties at the beginning in Step 2. Click Insert/Fields/Title.
- Now press Enter; the cursor moves down and it somehow automatically changes to the Subtitle style. Styles in OpenOffice allow you to choose a Next style (a followup style) and in this case, when someone presses Enter on the Title style, they get a new paragraph in the Subtitle style. While in the line/paragraph with Subtitle style, click on Insert/Field…/Subject. Fields in OpenOffice.org appear with a dark gray background; this does not appear in printing, it is just there to help you identify where the fields are.
- Now lets move to the last page, the page with Default style and write something. Select the Heading 1 paragraph style and type Introduction. Press enter and you notice that the next style is Text body. Text body is the natural paragraph style for text in Writer (most documents have the default Default paragraph style which is wrong). Now write something in Text Body such as I love writing documents in OpenOffice.org Writer. Copy the line and paste several times so that we get a nice paragraph of at least five lines. Make sure when pasting that after a full stop there should be a single space, then the new sentence starts.
- Press Enter and now we are ready to add a new heading. Type Writing documents and set the Heading 1 paragraph style. Press Enter and fill up a paragraph with more of I love writing documents in OpenOffice.org Writer.
- Press Enter and create a new section (add a Heading 2, name it Writing documents in style and fill up a corresponding paragraph).
- Press Enter and create a last section (add a Heading 1, name it Conclusion, and fill up a corresponding paragraph style).
- Now we are ready to place the cursor at the Index page we created before, and go for the Table of Contents. Click on Insert/Indexes and Tables/Indexes and Tables. The default index type is Table of Contents. We keep the default settings and click OK. We get a nice looking table of contents.
- At this stage we have a complete basic document, with first page, index page and default page.
The next set of steps include more polishing and adding extra elements to our document.
- The text body style is configured to have the left alignment by default. Normally, one would select paragraphs and click on a paragraph alignment button on the toolbar to change the alignment. Because we are using styles, we can modify the Text Body style to have another alignment, and presto the whole document with text in the same style follow suit. In the Styles and Formating dock, at the paragraph styles tab, select the Text Body style. Right-click on the Text Body style and choose to Modify style. Find the Alignment tab and choose Justified as the new alignment for Text Body paragraphs. Click Ok and observe the document changing to the new configuration.
- It is nice to the section numbers on the headings, such as 2.1 Writing documents in style. To do this, we need to change the default outline numbering. Click on Tools/Outline numbering… and select to modify the numbering for all levels (under Level, click 1-10). Then, under the Numbering group, change the Number option from the default None to 1, 2, 3, …. Click OK and the number is changed in the document.
- Go back to the Table of Contents. You notice that the numbering format does not look nice; some section numbers are too close to the section names. To fix, right click on the gray area of the table of contents and select Edit Index/Table. In the new dialog box, select the Entries tab. Under Structure and Formatting you can see the structure of each line of line in the table of contents table. The button labeled E# is the placeholder for the chapter number. After that there is a placeholder that you can actually type text. In our case we simply click and press the space bar to add another space. We then click the All button and finally click OK. Now, all entries in the Table of contents will have a space between the chapter number and chapter title.
- In order to add a footer with the current page number, click on Insert/Footer and pick Index, then Default. Both the Index and the Default style of pages get to show page numbers. Then, place the cursor in the footer area and Insert/Field/Page Number. You can modify the Footer paragraph style so that the text alignment is centered. You have to insert the field in both an Index page and a Default page.
- The page number in the Index page is commonly shown in Roman lowercase numbers. How can we fix that? We simply have to modify the Index page style accordingly; click on the Page Styles tab in Styles and Formatting, click to modify the Index page style, and at the Page tab in Layout Settings select the i, ii, iii, … format. Click OK.
- It would be nice to have the title on the header of each page, either Index or Default. Click on Insert/Header and add a header for Index and Default. Then, place the cursor in the header for both styles and click to add the Title field (Insert/Field/Title). Would it be nice to put a line under the header? The header text has the Header paragraph style. In the Styles and Formatting, click the Paragraph styles tab and select the Header paragraph style. Right-click and choose to Modify. In the Borders tab enable a bottom line and click OK.
You can download this sample document (.odt) from the link Using OpenOffice.org Writer.
I’ll stop here for now. There are more to put such as Table of Figures, Index of Tables and Bibliography.
It would be good to leave feedback if there is interest to work on this direction.
Update 15Mar2008: This appears to be a Farsi translation/adaptation of the article.
The Google Highly Open Participation Contest
One more initiative by Google to reach out to the community and promote free and open-source software is the The Google Highly Open Participation Contest 2007/2008.
The purpose of the competition is to enable young students older than 13 years old but have not entered yet the tertiary education, to participate in open-source development.
To get started, read the Official Contest Rules and the Frequently Asked Questions (FAQ) pages.
There are ten projects to choose to work from, one of which is GNOME, the desktop environment found in Linux distributions such as Ubuntu Linux and Fedora.
The current list of items to work on for GNOME include several documentation and translation tasks. If there is interest to work on the Greek localisation, leave a comment at this post. The direction I propose is to help with translating the documentation of GNOME applications.
Open-source software progresses by having more people contributing. This effort by Google and also previous efforts (Google Summer of Code) help tremendously towards the wider participation.
One-line hardware support (USB Wireless Adapter)
I got recently a USB Wireless Adaptor, produced by Aztech. It was a good buy for several reasons:
- It advertised Linux support
- It was affordable
- It had good quality casing; you can step on it and it won’t break
- It had the Penguin on the box and was really really cheap
When I plugged it in on my Linux system, it did not work out of the box. The kernel acknowledged that a USB device was inserted (two lines in /var/log/messages) but no driver claimed the device.
With the package came a CD which had drivers for several operating systems, including Linux. Apparently one would need to install the specific driver. I think the driver was available in both source code and as a binary package (for some kernel version).
The kernel module on the CD was called zd1211, so I checked whether my kernel had such a module installed. To my surprise, there was such a kernel module, called zd1211rw. I hope you have better chance with the URL because now the website appears to be down (Error 500).
Therefore, what was wrong with my zd1211rw kernel module? Reading the documentation of project website, I figured out that you have to report the ID (called the USB ID) of your adapter so that it is included in the kernel module, and when you plug in your device, it will be automatically detected.
You can find the USB ID by running the command lsusb. Then, it is a one-line patch for the zd1211rw driver to add support for the device,
— zd1211rw.linux2.6.20/zd_usb.c 2007-09-25 14:48:06.000000000
+0300
+++ zd1211rw/zd_usb.c 2007-09-28 11:35:51.000000000 +0300
@@ -64,6 +64,7 @@
{ USB_DEVICE(0x13b1, 0×0024), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0×0586, 0x340f), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x0baf, 0×0121), .driver_info = DEVICE_ZD1211B },
+ { USB_DEVICE(0x0cde, 0x001a), .driver_info = DEVICE_ZD1211B },
/* “Driverless” devices that need ejecting */
{ USB_DEVICE(0x0ace, 0×2011), .driver_info = DEVICE_INSTALLER },
{ USB_DEVICE(0x0ace, 0x20ff), .driver_info = DEVICE_INSTALLER },
What Aztech should have done is to submit the USB ID to the developers of the zd1211rw driver. In this way, any Linux distribution that comes out with the updated kernel will have support for the device.
It is very important to get the manufacturers to change mentality. From offering a CD with “drivers”, for free and open-source software they should also work upstream with the device driver developers of the Linux kernel. The effort is small and the customer benefits huge.
My Akismet spam count in WordPress
Here is the Akismet spam count of my WordPress blog,
All spam deleted.
Caught SpamAkismet has caught 316,645 spam for you since you first installed it.
You have no spam currently in the queue. Must be your lucky day.
![]()
WordPress
Documentation — Support Forums
2.1 — 0.10 seconds
Using SVN for GNOME Translators
Update 3rd June 2009: This is a very old post when GNOME was using SVN for the VCS (now we use git). My blog theme does not show the year, so I am writing this in case you are confused by the post.
Now GNOME uses SVN to manage the development of the software.
To use SVN, the basic relevant commands are described at Getting the most out of Subversion in GNOME.
If you are a translator, the work is further simplified. You would normally new SVN to get a copy of the source code of a package so that you can extract the translation messages of the UI or the documentation. In addition, in some cases you can provide localised images and screenshots.
First of all, if you do not have an account on SVN yet, you need to connect using Anonymous access. You still have all access, however if you want to upload any translations would need to give them to someone else who has such an SVN account.
Furthermore, the source code of a package is often branched during a GNOME release so that when there is ongoing development, the released version of the package is not affected. Branches usually have a name similar to gnome-2-18. The not-branched branch is called trunk (or HEAD, in CVS lingo), where all cutting-edge development usually happens.
To checkout (here checkout means to obtain a copy) the source code of a package.
Checkout trunk as anonymous
svn checkout http://svn.gnome.org/svn/gnome-utils/trunk my-trunk-gnome-utils
Checkout trunk as simos
svn checkout svn+ssh://simos@svn.gnome.org/svn/gnome-utils/trunk my-trunk-gnome-utils
Checkout branch called “gnome-2-18″ as anonymous
svn checkout http://svn.gnome.org/svn/gnome-utils/branches/gnome-2-18/ gnome-utils-stable
Checkout branch called “gnome-2-18″ as simos
svn checkout svn+ssh://simos@svn.gnome.org/svn/gnome-utils/branches/gnome-2-18 gnome-utils-stable
To commit you changes means that you send your changes upstream to the project.
In order to commit, you enter the directory you checked out and you run
svn commit -m “Updated Greek translation”
The changes you make typically include updated your language’s LL.po file, and also updating the ChangeLog file.
You cannot commit in a anonymous checkout. The system knows that it’s you when you are commiting because the checkout command saved the username you used earlier.
In the SVN commands, you can abbreviate checkout with co, and commit with ci. Sometimes this leads to the most common newbie error; you tend to think that co is for commit. In practice you cannot make a mess though, as the command line parameters between the two actions are very different, and the command will fail.


