Tag : i18n

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.

Designing a command-line translation tool for GNOME

One messy task with GNOME translations is the whole workflow of getting the PO files, translating/updating/fixing them, and then uploading them back. One would need to use command line, and several different commands to accomplish this.

KDE and KBabel has a nice feature that allows you to easily grab all translation files, work on them, then commit through SVN. All through the GUI! It helps a bit here that the translation files for a specific language are located under a single directory.

The current workflow in GNOME translations typically consists of

  1. Getting the PO file from the L10n server (for example, GNOME 2.22 Greek) (also possible to use intltool-update within po/)
  2. Translate using KBabel, POEdit, GTranslator, vim, emacs, etc.
  3. svn co the package making sure you have the correct branch. One may limit to the po/ directory.
  4. Put the updated file in po/
  5. Update the ChangeLog (either with emacs, or with that Perl script)
  6. Commit the translation.
  7. (If you committed on a branch, also commit on HEAD)

Tools such as Transifex (used currently in Fedora) take away altogether the use of command line tools, and one works here through a web-based interface. Apparently, Transifex is having a command-line tool in the TODO list.
What I would like to see in GNOME translations, is a tool that one can use to

  1. Grab all or a section of the PO files from GNOME 2.22. Put them in a local folder.
  2. Use the tools of my preference (translation tools, scripts, etc) to update those translations I need to update.
  3. Commit those translation files that changed (using my SVN account), automatically add ChangeLog entries, also commit to HEAD if required.

I would prefer to have a command-line tool for this, for now, though it would be great if GUI tools would get the same functionality at some point. For a command line tool, the workflow would look like

The workflow would be something like

$ ssh-add
Enter passphrase for /home/simos/.ssh/id_rsa:
Identity added: /home/simos/.ssh/id_dsa (/home/simos/.ssh/id_dsa)
$ tsfx --project=gnome-2.22 --language=el --collection=gnome-desktop --user=simos --action=checkout
Reading from http://svn.gnome.org/svn/damned-lies/trunk/releases.xml.in... done.
Getting alacarte (HEAD)... done.
Getting bug-buddy (branch: xyz)... done.
...
Completed in 4:11s.
$ _

Now we translate any of the files we downloaded, and we push back upstream (of course, only those files that were changed).

$ tsfx --action=commit
Found local repository, Project: gnome-2.22, Language: el, Collection: gnome-desktop, User: simos
 Reading local files...
Found 6 changed files.
Uploading alacarte (HEAD)... done.
Uploading bug-buddy (branch:xyz, HEAD)... done.
...
Completed uploading translation files to gnome-2.22, language el.
$ _

Important MO file optimisation for en_* locales, and partly others

During GUADEC, Tomas Frydrych gave a talk on exmap-console, a cut-down version of exmap that can work well on mobile devices.

During the presentation, Tomas showed how to use the tool to find the culprits in memory (ab)use on the GNOME desktop. One issue that came up was that the MO files taking up space though the desktop showed English. Why would the MO translation files loaded in memory be so big in size?

gtk20.mo                             : VM   61440  B, M   61440  B, S   61440  B

atk10.mo                      	     : VM    8192  B, M    8192  B, S    8192  B

libgnome-2.0.mo			: VM   28672  B, M   24576  B, S   24576  B

glib20.mo			     : VM   20480  B, M   16384  B, S   16384  B

gtk20-properties.mo           : VM     128 KB, M     116 KB, S     116 KB

launchpad-integration.mo  : VM    4096  B, M    4096  B, S    4096  B

A translation file looks like

msgid “File”

msgstr “”

When translated to Greek it is

msgid “File”

msgstr “Αρχείο”

In the English UK translation it would be

msgid “File”

msgstr “File”

This actually is not necessary because if you leave those messags untranslated, the system will use the original messages that are embedded in the executable file.

However, for the purposes of the English UK, English Canadian, etc teams, it makes sense to copy the same messages in the translated field because it would be an indication that the message was examined by the translation. Any new messages would appear as untranslated and the same process would continue.

Now, the problem is that the gettext tools are not smart enough when they compile such translation files; they replicate without need those messages occupying space in the generated MO file.

Apart from the English variants, this issue is also present in other languages when the message looks like

msgid “GConf”

msgstr “GConf”

Here, it does not make much sense to translate the message in the locale language. However, the generated MO file contains now more than 10 bytes (5+5) , plus some space for the index.

Therefore, what’s the solution for this issue?

One solution is to add to msgattrib the option to preprocess a PO file and remove those unneeded copies. Here is a patch,

— src.ORIGINAL/msgattrib.c 2007-07-18 17:17:08.000000000 +0100
+++ src/msgattrib.c 2007-07-23 01:20:35.000000000 +0100
@@ -61,7 +61,8 @@
REMOVE_FUZZY = 1 << 2,
REMOVE_NONFUZZY = 1 << 3,
REMOVE_OBSOLETE = 1 << 4,
– REMOVE_NONOBSOLETE = 1 << 5
+ REMOVE_NONOBSOLETE = 1 << 5,
+ REMOVE_COPIED = 1 << 6
};
static int to_remove;

@@ -90,6 +91,7 @@
{ “help”, no_argument, NULL, ‘h’ },
{ “ignore-file”, required_argument, NULL, CHAR_MAX + 15 },
{ “indent”, no_argument, NULL, ‘i’ },
+ { “no-copied”, no_argument, NULL, CHAR_MAX + 19 },
{ “no-escape”, no_argument, NULL, ‘e’ },
{ “no-fuzzy”, no_argument, NULL, CHAR_MAX + 3 },
{ “no-location”, no_argument, &line_comment, 0 },
@@ -314,6 +316,10 @@
to_change |= REMOVE_PREV;
break;

+ case CHAR_MAX + 19: /* –no-copied */
+ to_remove |= REMOVE_COPIED;
+ break;
+
default:
usage (EXIT_FAILURE);
/* NOTREACHED */
@@ -436,6 +442,8 @@
–no-obsolete remove obsolete #~ messages\n”));
printf (_(“\
–only-obsolete keep obsolete #~ messages\n”));
+ printf (_(“\
+ –no-copied remove copied messages\n”));
printf (“\n”);
printf (_(“\
Attribute manipulation:\n”));
@@ -536,6 +544,21 @@
: to_remove & REMOVE_NONOBSOLETE))
return false;

+ if (to_remove & REMOVE_COPIED)
+ {
+ if (!strcmp(mp->msgid, mp->msgstr) && strlen(mp->msgstr)+1 >= mp->msgstr_len)
+ {
+ return false;
+ }
+ else if ( strlen(mp->msgstr)+1 < mp->msgstr_len )
+ {
+ if ( !strcmp(mp->msgstr + strlen(mp->msgstr)+1, mp->msgid_plural) )
+ {
+ return false;
+ }
+ }
+ }
+
return true;
}
However, if we only change msgattrib, we would need to adapt the build system for all packages.

Apparently, it would make sense to change the default behaviour of msgfmt, the program that compiles PO files into MO files.

An e-mail was sent to the email address for the development team of gettext regarding the issue. The development team does not appear to have a Bugzilla to record these issues. If you know of an alternative contact point, please notify me.

Update #1 (23Jul07): As an indication of the file size savings, the en_GB locale on Ubuntu in the installation CD occupies about 424KB where in practice it should have been 48KB.

A full installation of Ubuntu with some basic KDE packages (only for the basic libraries, i.e. KBabel – (ls k* | wc -l = 499)) occupies about 26MB of space just for the translation files. When optimising in the MO files, the translation files occupy only 7MB. This is quite important because when someone installs for example the en_CA locale, all en_?? locales are added.

The reason why the reduction is more has to do with the message types that KDE uses. For example,

msgid “”
“_: Unknown State\n”
“Unknown”
msgstr “Unknown”

I cannot see a portable way to code the gettext-tools so that they understand that the above message can be easily omitted. For the above reduction to 7MB, KDE applications (k*) occupy 3.6MB. The non-KDE applications include GNOME, XFCE and GNU traditional tools. The biggest culprits in KDE are kstars (386KB) and kgeography (345KB).

Update #2 (23Jul07): (Thanks Deniz for the comment below on gweather!) The po-locations translations (gnome-applets/gweather) of all languages are combined together to generate a big XML file that can be found at usr/share/gnome-applets/gweather/Locations.xml (~15MB).

This file is not kept in memory while the gweather applet is running.
However, the file is parsed when the user opens the properties dialog to change the location.
I would say that the main problem here is the file size (15.8MB) that can be easily reduced when stripping copied messages. This file is included in any Linux distribution, whatever the locale.

The po-locations directory currently occupies 107MB and when copied messages are eliminated it occupies 78MB (a difference of 30MB). The generated XML file is in any case smaller (15.8MB without optimisation) because it does not include repeatedly the msgid lines for each language.

I regenerated the Locations.xml file with the optimised PO files and the resulting file is 7.6MB. This is a good reduction in file space and also in packaging size.

Update #3 (25Jul07): Posted a patch for gettext-tools/msgattrib.c. Sent an e-mail to the kde-i18n-doc mailing list and got good response and a valid argument for the proposed changes. Specifically, there is a case when one gives custom values to the LANGUAGE variable. This happens when someone uses the LANGUAGE variable with a value such as “es:fr” which means show me messages in Spanish and if something is untranslated show me in French. If a message has msgid==msgstr for Spanish but not for French, then it would show in French if we go along with the proposed optimisation.

OpenVistA information system for hospitals and medical care

It is quite common to expect the availability of free and open-source software for common needs, such as an operating system and an office suite. What is the situation when your needs are much more advanced? Such as, when you are looking for an information system for a hospital?
Luckily, there is such a software package for an information system for hospital needs, called OpenVistA. OpenVistA comes from VistA, a public-funded medical system for the United States Department of Veterans Affairs. Due to the source of the funding, the source code of the medical system has been available with a liberal license, and gave birth to OpenVistA.
An interesting issue with OpenVistA is that the backend is written with the MUMPS programming language. This programming language is quite old with syntax dissimilar to modern languages. However, MUMPS has become popular in medical care systems and especially VistA. There are people that criticize the programming language; it is important to understand that a big piece of software working well has much more weight over the language preferences. In addition, the front-end is what the end-user uses, and in our case it is written with modern programming languages.
Screenshot of Mono frontend of OpenVistA
Traditionally, the major front-end of OpenVistA was written in Delphi. Quite recently, a new front-end has been written, in Mono. Thanks to Mono, the front-end is cross-platform and supports i18n (the front-end can be translated in many written languages).
You can try out OpenVistA straight away by downloading the OpenVistA VMWare appliance (image file that contains an installation of an operating system, configured and ready to use). The specific VMWare appliance is based on Xubuntu.
Software for hospitals is quite expensive, and is a lucrative business for software houses. However, when one takes into account that in many countries hospitals are public-funded, it is easy to understand how important it is to use free and open-source software in this case. Sadly, in many cases, hospitals make ad-hoc agreements for such software, resulting to inefficient use of public funds.

Creating a new locale on the OLPC

When you run the OLPC software you currently have access only to the English locales.

If you want to enable Greek support, you need to run (as root)

localedef -v -c -i /usr/share/i18n/locales/el_GR -f UTF-8 /usr/lib/locale/el_GR/

localedef -v -c -i /usr/share/i18n/locales/el_GR -f UTF-8 /usr/lib/locale/el_GR.utf8/

You will get a bunch of warnings. You can ignore them for now.

The localedef command compiles the source locale information found at /usr/share/i18n/locales/el_GR and places the resulting files at
/usr/lib/locale/el_GR/ and /usr/lib/locale/el_GR.utf8/ (both directories contain the same files, so you can also make a link from one to another). The reason we make two versions is that we can use either el_GR or el_GR.utf8 in the applications. Both use UTF-8 as the base encoding which is always nice.
For other locales, replace el_GR with the locale name of your country.

To activate the Greek locale, you need to create a file /etc/sysconfig/i18n and add the text

LANG=el_GR.utf8

LANGUAGE=el:en

Now you need to place the translated applications (.mo format) into

/usr/share/locale/el/LC_MESSAGES/

and restart your virtual machine (or laptop (hint hint)).

Translating the OLPC

In a previous post, we covered how to install fonts and enabling writing support on the OLPC. The OLPC contains a limited number of applications that are available to be translated. These applications include

  1. NetworkManager, part of the GNOME project (HEAD, extras)
  2. alsa-utils, ???
  3. aspell, external
  4. atk10, part of the GNOME project (GNOME 2.18, developer)
  5. chkconfig, part of the Fedora Project
  6. diffutils, external
  7. glib20, part of the GNOME project (GNOME 2.18, developer)
  8. gst-plugins-base-0.10, external
  9. gst-plugins-good-0.10, external
  10. gstreamer-0.10, external
  11. gtk20-properties, part of the GNOME project (GNOME 2.18, developer)
  12. gtk20, part of the GNOME project (GNOME 2.18, developer)
  13. hal, external
  14. initscripts, part of the Fedora Project
  15. libc, part of the Translation Project (reduced version?)
  16. libuser, part of the Fedora Project
  17. libwnck, part of the GNOME Project (GNOME 2.18, desktop)
  18. stardict, external
  19. vte, part of the GNOME Project (GNOME 2.18, desktop)
  20. wget, part of the Translation Project

The links provided point to the latest available version. The versions that the OLPC using are not the latest with the upstream project, therefore keep in mind that the translated files may differ. It would be good to establish the exact .PO files from the OLPC project (URL to source?).

Έργο εξελληνισμού της διανομής Fedora

Ο Δημήτρης κατέγραψε τα όσα έχουν γίνει και ποιες είναι οι εκρεμμότητες στο έργο εξελληνισμού της διανομής Fedora. Σε μερικούς μήνες θα έχουμε τη νέα έκδοση της διανομής Fedora, Fedora Core 6, και υπάρχουν μια σειρά από εργασίες για να κάνουμε τη διανομή να δουλέψει άψογα στα ελληνικά.

Αν και οι περισσότερες δουλειές εξελληνισμού γίνονται upstream στα επιμέρους έργο (π.χ. GNOME, KDE, Mozilla), υπάρχει ανάγκη ελέγχου των προεκδόσεων μιας διανομής για να είμαστε σίγουροι ότι ο τελικός χρήστης δεν θα έχει προβλήματα. Έτσι, θέματα όπως ποια είναι η βασική γραμματοσειρά συστήματος είναι ένα θέμα εξελληνισμού που για τώρα πρέπει να το επαναλαμβάνουμε για κάθε διανομή.

Διαβάστε λοιπόν την ενημέρωση του έργου εξελληνισμού της διανομής Fedora.

Re: gtk1.x και Ελληνικά

Ο Νίκος Νύκταρης έγραψε:
Μιας και από φαίνεται δεν μου κάθεται μια νέα έκδοση του  knoppel είπα να
ασχοληθώ με μερικά bugs που κάποια στιγμή είχα συναντήσει.
Παρακάτω είναι ένα από αυτά και αφορά τις εφαρμογές gtk1.x και τα Ελληνικά ,
θα ήθελα τη γνώμη σας πριν κάνω κανένα bugreport που είναι άχρηστο ή λάθος.
Το πρόβλημα λοιπόν είναι η εμφάνιση των ελληνικών στις εφαρμογές gtk1.x που
συναντώ εδώ και καιρό (από τότε που βγήκε το x.org) στο Debian. Κάνοντας πριν
μερικές μέρες εγκατάσταση του τελευταία έκδοση του etch τα Ελληνικά  στο xmms
εμφανίζονται όπως στο
The image “https://i0.wp.com/www.knoppel.org/gtkbug/xmms1.png” cannot be displayed, because it contains errors.

Εδώ βλέπουμε ότι τα μεταφρασμένα μηνύματα της εφαρμογής είναι σε μορφή Unicode (για μονοτονικό είναι 2 byte ανά χαρακτήρα). Το XMMS για κάποιο λόγο δεν καταλαβαίνει ότι τα μηνύματα είναι σε μορφή UTF-8 με αποτέλεσμα να προσπαθεί να απεικονίσει κάθε byte ως χαρακτήρα από μια κωδικοποίηση 8-bit. Η επανάληψη του χαρακτήρα & υποδεικνύει το πρόβλημα αυτό.

Αυτό το πρόβλημα είχε αναφερθεί και για την ρώσικη γλώσσα καιρό πριν (debian
bug 330144) το οποίο και λύθηκε για αυτούς. (είναι το bug που έλεγα πριν από
καιρό στον simo)
Για αντίστοιχη λύση για τα Ελληνικά έχουμε δύο κομμάτια. Το ένα αφορά την
γραμματοσειρά που υπάρχει στο /etc/gtk/gtk.utf8 που προφανώς δεν υποστηρίζει
σωστά τα Ελληνικά
Ανοίγοντας το αρχείο και αλλάζοντας την γραμματοσειρά σε fixed το αποτέλεσμα
είναι το όπως εμφανίζεται στο

https://i2.wp.com/www.knoppel.org/gtkbug/xmms2.png

Τη διαφορά στο αποτέλεσμα μεταξύ των δύο παραπάνω στιγμιοτύπων οθόνης το λαμβάνεις με την απλή αλλαγή της γραμματοσειράς; Αυτό μπορεί να σημαίνει ότι η πρώτη γραμματοσειρά δεν είναι Unicode.

Από όσο γνωρίζω, η παραπάνω γραμματοσειρά είναι μια από τις Ασιατικές γραμματοσειρές.

Προφανώς δεν είναι ότι καλύτερο αισθητικά
Και επανέρχομαι στο bug 330144 και παρατηρώ ότι τα δικά μας αρχεία
στο /usr/share/X11/locale/el_GR.UTF-8 υπάρχουν μεν αλλά  είναι κενά. και από
φαίνεται στο locale.dir έτσι και αλλιώς δεν χρησιμοποιούνται.
Τα δημιούργησα λοιπόν και πρόσθεσα τις δύο κωδικοποιήσεις iso8859-7 και cp1253
που δεν υπάρχουν στο αντίστοιχο Αγγλικό αρχείο. Άλλαξα το locale.dir να
χρησιμοποιεί τα νέα αρχεία το αποτέλεσμα είναι όπως εμφανίζεται στο

The image “https://i2.wp.com/www.knoppel.org/gtkbug/xmms3.png” cannot be displayed, because it contains errors.

Να σημειώσω ότι έτσι και αλλιώς το αρχείο /etc/gtk/gtk.utf-8 πρέπει να
αλλαχτεί διαφορετικά το αποτέλεσμα είναι όπως το

https://i0.wp.com/www.knoppel.org/gtkbug/xmms4.png

Αυτό είναι πολύ παράξενο. Για να δείξει εκτεταμένους λατινικούς χαρακτήρες, η κωδικοποίηση της μετάφρασης του XMMS πρέπει να είναι 8-bit ή γίνονται παράξενες έμμεσες μετατροπές στην κωδικοποίηση. Μπορείς να επιβεβαιώσεις ότι η κωδικοποίηση της μετάφρασης του XMMS είναι UTF-8 και ότι η δήλωση στη κεφαλίδα είναι όντως UTF-8;

Προφανώς το αποτέλεσμα αισθητικά είναι πολύ καλύτερο. Το θέμα είναι είναι και
τεχνικά σωστό? Γιατί υπάρχουν τα αρχεία στο el_GR.UTF-8 και είναι κενά? Το
πρόβλημα αυτό υπάρχει και στις άλλες διανομές?
Ο κατάλογος el_GR.UTF-8 δεν χρειάζεται διότι αρκεί ο κατάλογος en_US.UTF-8. Η κωδικοποίηση είναι κοινή, UTF-8.
Για 8-bit ελληνικά (iso-8859-7) χρειάζεται τέτοιος κατάλογος που φυσικά είναι διαθέσιμος.
Παρακάτω ακολουθεί ένα link με τα αλλαγμένα αρχεία για όποιον θέλει να ελέγξει
τις αλλαγές ή/και να τις δοκιμάσει.

http://www.knoppel.org/gtkbug/gtkbug.tar.gz

Προσωπικά προτιμώ εφαρμογές που χρησιμοποιούν την κωδικοποίηση UTF-8 και άλλες επιλογές προσθέτουν πολυπλοκότητα που δεν έχουμε ανάγκη. Αν έχεις τη δυνατότητα να αλλάξεις την εφαρμογή XMMS σε μια από τις νεώτερες εκδόσεις που βασίζονται στο GTK2+, είναι η καλύτερη λύση.

Ακόμα, είναι καλό να αλλάξεις την βασική γραμματοσειρά συστήματος σε DejaVu (Dejavu Sans) διότι υποστηρίζει ελληνικά και είναι hinted.

Παρωχημένα πράγματα

παρωχημένος -η -ο [paroiménos] E3 : που ανήκει στο παρελθόν: O ιστορικός μελετά παρωχημένες εποχές. || (γραμμ.) Παρωχημένη λέξη / έκφραση. Παρωχημένη σημασία / χρήση μιας λέξης, που υπήρχε παλαιότερα. || (γραμμ.) ~ χρόνος, συντελεσμένος. [λόγ. < αρχ. παρῳχημένος (γραμμ.: ελνστ. σημ.)]

Πηγή: http://www.komvos.edu.gr/dictionaries/dictonline/DictOnLineTri.htm

Υπάρχει συζήτηση στη λίστα i18ngr για το αν είναι κατάλληλη η λέξη παρωχημένος για τη μετάφραση του όρου deprecated (π.χ. the use of the abort3() system call is deprecated).

Στην Πληροφορική, ο όρος deprecated έχει την έννοια της σταδιακής απόσυρσης ενός χαρακτηριστικού σε λογισμικό. Δηλαδή η λειτουργία είνα διαθέσιμη τώρα, ωστόσο στο μέλλον δεν θα είναι διαθέσιμη πια.

In computer software standards and documentation, deprecation is the gradual phasing-out of a software or programming language feature.

Πηγή: http://en.wikipedia.org/wiki/Deprecated

Η λέξη παρωχημένος τείνει να έχει αρνητικό connotation και σε μερικές καταστάσεις έχει χρήση ως βρισιά.

Ποιος είναι ο πιο κατάλληλος όρος για τη μετάφραση του deprecated;

Εξελληνισμός του OLPC

Από το γράμμα του κ. Καρούνου για την ελληνική έκδοση του OLPC, θα γίνει μια ομιλία σήμερα Δευτέρα, 27 Μαρτίου 2006, στις 19:30, στο Ινστιτούτο Γκαίτε (Ομήρου 14-16), από το Μιχάλη Βλέτσα (Chief Connectivity Officer του OLPC) για την εξέλιξη του έργου. Είναι σημαντικό να πάνε άτομα και να ενημερώσουν από την πλευρά τους.

Σχετικά με τα θέματα εξελληνισμού, έχουμε

  • υπάρχει ζήτημα με τις γραμματοσειρές στη διανομή Fedora, μιας και δεν υπάρχει γραμματοσειρά με καλή υποστήριξη ελ ηνικών. Προτείνουμε τη DejaVu.
  • για τη γραφή ελληνικών το θέμα είναι σε καλό επίπεδο. Θέλουμε να είναι ρυθμισμένο με την παροχή του OLPC η γραφή αγγλικών/ελληνικών με ενεργοποιημένο το συνδυασμό Alt-Shift για την εναλλαγή μεταξύ των διατάξεων.
  • GNOME και KDE είναι εξελληνισμένα – ποιο θα επιλεγεί;

Οι Νίκος Χαρωνιτάκης και Δημήτρης Μιχελινάκης έχουν μεταφράσει σε καλό βαθμό τις εφαρμογές που είναι ειδικές στη διανομή Fedora.

Πάντως, το αντικείμενο του κ. Βλέτσα είναι οι ασύρματες επικοινωνίες, που πιστεύω ότι έχουν το ίδιο ενδιαφέρον με τον εξελληνισμό. Ερωτήματα για ασύρματες επικοινωνίες

  • θα γίνει χρήση του chipset atheros;
  • θα γίνει χρήση του οδηγού madwifi ή της ελεύθερης έκδοσης;
  • υπάρχουν βελτιστοποιήσεις για την κεραία – ποια θα είναι η εμβέλεια;
  • χρήση του OLPC για σύνδεση στα ασύρματα μητροπολιτικά δίκτυα της Ελλάδας;

 Ενημέρωση (28Μαρ06):

Θα γίνει χρήση chipset ασύρματου δικτύου της Marvell και συγκεκριμένα η έκδοση USB του Marvell 88w8388. Το chipset αυτό έχει αρκετές από λειτουργίες ενσωματωμένες, με αποτέλεσμα να καταναλώνει το σύστημα λιγότερη ενέργεια. Για παράδειγμα, ο φορητός θα είναι σε θέση να αποτελεί μέρος σε δίκτυο mesh όταν και η CPU είναι εκτός τροφοδοσίας.

Άλλα τεχνικά στοιχεία υπάρχουν στο Wiki του έργου OLPC.

Ανατομία ενός γράμματος

Με ενδιαφέρον είδα μια συζήτηση (τίτλος upgrade σε ubuntu 5.10 = προβλήματα με τα ελληνικά) στη λίστα συνδρομητών Linux-greek-users για το θέμα της υποστήριξης γραφής ελληνικών σε ελεύθερο λογισμικό.
Ωστόσο, μετά από λίγα γράμματα, στάλθηκε (more…)