Re: on usage of non-ascii symbols

[Simos Xenitellis]

On Tue, 2007-02-27 at 09:07 +0700, Nguyen Thai Ngoc Duy wrote:
> On 2/27/07, Leonardo Fontenelle <[EMAIL PROTECTED]> wrote:
> > Epiphany uses real ellipsis like this, and curly double quotation
> > marks (in opposition to the common, "vertical" one). Unicode gives us
> > a lot of unambiguous characters for situations like that, and many
> > people (ex. web standards people) think you should use them as often
> > as possible. I kind of agree with that, too, but as you said they are
> > hard to enter and most people don't like them that much. Recently I
> > talked to the rest of the pt_BR l10n team and we decided not to use
> > this "nice and hard" unicode chars.
> 
> Using such characters would be great if the font users are using
> supports them. I'm certain Bitstream does but what if users use
> another font that doesn't? (hey if pango can determine such situations
> and auto convert to ascii alternatives.. i'm dreaming..)

Fontwise, the default font in at least Ubuntu and Fedora Core is DejaVu,
which is based on Bitstream. It is actually DejaVu that provides support
to all those fancy Unicode characters. For example, when you enter your
password at login, you see some big black dots in the place of the
standard asterisks. This is a Unicode character, introduced with the
adoption of DejaVu.
You can view the current list of those extended Unicode characters using
Applications/Accessories/Character Map. Select to View by Unicode Block.
To identify which font provides a specific character, right-click on the
displayed character and it will show you which font it came from. The
fonts named "Sans", "Serif" and "Monospace" are sort of virtual fonts;
the system populates them with characters from the repertoire of the
system. DejaVu provides quite of a lot of those characters.

Simos



signature.asc
Description: This is a digitally signed message part
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: on usage of non-ascii symbols

[Simos Xenitellis]

On Wed, 2007-02-28 at 00:39 +0800, Abel Cheung wrote:
> On 2/27/07, Karl Eichwalder <[EMAIL PROTECTED]> wrote:
> > > Epiphany uses real ellipsis like this, and curly double quotation
> > > marks (in opposition to the common, "vertical" one). Unicode gives us
> > > a lot of unambiguous characters for situations like that, and many
> > > people (ex. web standards people) think you should use them as often
> > > as possible. I kind of agree with that, too, but as you said they are
> > > hard to enter and most people don't like them that much.
> >
> > You'd better avoid such eye-candy stuff in source code.  Instead do
> > proper English translations and add en_US and en_GB files.
> 
> I can recall in some older discussion that current GNOME 'policy' is
> "source code == en_US".

I think that should be "source code == ASCII printable characters plus
the Character Escape Codes
(http://en.wikipedia.org/wiki/ASCII#endnote_3)", as in
http://en.wikipedia.org/wiki/ASCII

That is from index 32 to 126 in ASCII and corresponds to exactly the
same with UTF-8, including some non-printable characters such as
newline, tab and so on.

If there are any data, they are stored as hex values or something
similar.

Is there a reference to something like this?

Simos



signature.asc
Description: This is a digitally signed message part
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Keeping track of branched modules

[Simos Xenitellis]

On Mon, 2007-03-05 at 08:03 +0300, Ilkka Tuohela wrote:
> Is it possible to get a raw text module branching list to the
> progress.gnome.org site?
> 
> I'm on the list, but it's so easy to miss a message about some
> branched module sometimes, and you end up translating HEAD and
> wonder why the module status does not change on the progress
> pages at all.
> 
> I would prefer something directly linked from release toplevel
> of the progress pages for, listing all modules and their versions
> in a format you can automate to check local copies, example:
> 
> - from page http://l10n.gnome.org/releases/gnome-2-18 we could
>   have a link on top 'current module branches'
> - current module branches can be a normal web page, but I would
>   like to get a plain text file as well, for example like:
> 
> wget -O- http://l10n.gnome.org/releases/gnome-2-18/branches.txt
> [platform]
> gtk+  gtk-2-10
> glib  trunk
> [desktop]
> alacarte   trunk
> evolution  trunk
> [developer]
> devhelptrunk
> glade3 trunk
> 
> Format of this file is irrelevant, just something you can parse
> automatically. Of course when we have the file itself, we should
> provide scripts to use it:
> 
> - pull all source trees for given release set
> - check against local release set tree and check if any modules
>   have been branched for which you have a trunk copy of
> - whatever useful we can think of
> 
> As far as I understand this file can be generated automatically by
> the code which updates the progress pages, so it should not be too
> big task to implement, or if the progress pages are in database, it
> could pull current release set configuration automatically.
> 
> I'm happy to help implementing this, but just wanted to start first
> discussion... we might already have this, or my ideas could be maybe
> done better somehow.

There is releases.xml.in from the damned-lies module, as shown at
http://svn.gnome.org/viewcvs/damned-lies/trunk/

Some pretty page with the info would be beneficial.

Simos



signature.asc
Description: This is a digitally signed message part
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

glade and glade3 translation issues

[Simos Xenitellis]

Hi All,
I think there is chance for confusion between "glade" and "glade3" among
translators.
"glade" at http://svn.gnome.org/viewcvs/glade/trunk/po/
"glade3" at http://svn.gnome.org/viewcvs/glade3/trunk/po/
The former has 53 files while the latter only 40. There is a discrepancy
of 13 files, or language teams prone to translate glade3 from scratch or
working on the old "glade".
GNOME 2.18 uses glade3, as in
http://l10n.gnome.org/languages/el/gnome-2-18

Teams that need notification include
1. Nepali ("pachimho") - move translation from "glade" to "glade3".
2. Greek :( - we are sorting it out.
3. Spanish - there is a more recent update in "glade" than "glade3".
4. Russian - "lkanter" worked on "glade" a few months ago, "nshmyrev" is
on "glade3".
5. Catalan - as with Russian, "joseppc" and "jmas".

The following list shows the differences in the respective po/ folders.
If there is a - on the line, it means "glade" has the file but "glade3"
does not. That's the case where a person would translate from scratch
without taking advantage of previous work.

-am.po 
 ar.po 
 az.po 
-be.po 
 ca.po 
-cs.po 
 da.po 
 de.po 
-el.po 
 en_CA.po 
 en_GB.po 
 es.po 
 fi.po 
 fr.po 
-ga.po 
 gl.po 
-hr.po 
 hu.po 
-it.po 
 ja.po 
 ko.po 
-lv.po 
+lt.po 
 mk.po 
 ml.po 
 ms.po 
 nb.po 
-ne.po 
 nl.po 
 nn.po 
 pa.po 
 pl.po 
 pt.po 
 pt_BR.po 
-ro.po 
 ru.po 
-rw.po 
 sk.po 
-sq.po 
-sr.po 
[EMAIL PROTECTED] 
 sv.po 
+ta.po 
+th.po 
 tr.po 
 uk.po 
 vi.po 
-yi.po 
 zh_CN.po 
+zh_HK.po 
 zh_TW.po 

Shall I bugzilla these?

Simos



signature.asc
Description: This is a digitally signed message part
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Introducing open-tran.eu

[Simos Xenitellis]

On Mon, 2007-03-26 at 19:31 +0200, Jacek Śliwerski wrote:
> Few weeks ago I have launched a service for open source translators at 
> http://open-tran.eu.  It lets people search English phrases used in open 
> source software for their translation into 87 languages. Right now one 
> can search for translations of KDE and Mozilla and so I thought that you 
> might be interested in it.
> 
> I will be grateful for any feedback and criticism.

Great work Jacek!

If you would like to add in the GNOME translations, I believe you can
grab them with

wget -N -A el.po -r http://l10n.gnome.org/languages/el/gnome-2-18

The above example is for the Greek "el" translations. The current stable
version of GNOME is 2.18. You can find all GNOME releases at
http://l10n.gnome.org/releases/

All the best,
Simos



signature.asc
Description: This is a digitally signed message part
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Introducing open-tran.eu

[Simos Xenitellis]

On Tue, 2007-03-27 at 20:58 +0200, Jacek Śliwerski wrote:
> I know that Simos have already forwarded my email to this mailing list, 
> but I would like to "officially" introduce you my project:
>   http://open-tran.eu
> 
> I claim it to be the world's largest software-related dictionary.  And 
> since it is based on translations of Gnome, KDE and Mozilla, I thought 
> that you might be interested in it.
> 
> I'd like to thank you for your contributions to the Gnome project.  Your 
> work is an important part of Open-Tran.
> 
> I will be more than glad to know what you think about the project.

Thanks Jacek!

I would like to ask how you choose which GNOME .po files to use.
At http://open-tran.eu/db.html it mentions that "trunk" is being used.
Do you use the collection of packages that belong to the GNOME 2.18
release?

I would think that using the GNOME 2.18 release PO files would be a good
option, as they are tested more. Otherwise the quality of the results
will be reduced.

Simos


signature.asc
Description: This is a digitally signed message part
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Introducing open-tran.eu

[Simos Xenitellis]

On Wed, 2007-03-28 at 19:47 +0200, Andre Klapper wrote:
> Am Mittwoch, den 28.03.2007, 19:37 +0200 schrieb Jacek Śliwerski:
> > Gudmund Areskoug wrote:
> > Being honest - I have no idea, which version I use.  I have downloaded 
> > the translations from svn.gnome.org/svn/.../trunk.  How can I tell which 
> > version of Gnome it is?
> 
> svn.gnome.org/svn/.../trunk
>   is the current trunk/HEAD where the latest, unstable development takes
> place.
> 
> svn.gnome.org/svn/.../branches/gnome-2-18
>   is the current stable branch, named "gnome-2-18". note that not every
> module uses the name "gnome-2-18", it's only the proposed branch name.

If you want to get the precise list of what branch corresponds to each
GNOME release, you would need to parse the file releases.xml.in that is
found in 
http://svn.gnome.org/viewcvs/damned-lies/trunk/
The same file is used to generate the translation statistics, that also
show the individual updated .po files for each language. In this thread
I showed a simple wget command to grab the .po files for a specific
language. 

Those .po files from the statistics pages are "fresh" .po files; suppose
I last translated glade to Greek in 2003, then the .po file found on SVN
will probably be that old 2003 version. If you want to update the .po
file to reflect the current state of the codebase (old messages become
obsolete, new messages appear), you would need to run manually
"intltool-update el" in the "po" subdirectory. This should be on top of
the SVN checkout command. Now, the .po files that are found at the
translation pages are generated from precisely that "intltool-update LL"
command, and are always fresh.

What would be beneficial to have, follow each GNOME release
(http://l10n.gnome.org/releases/) or simply follow trunk?
My take would be to follow the current release (now "gnome-2-18"), and
when a new release comes we bother you to update it.
Christian, Danilo, what do you think?

One addition to the open-tran project I would like to see is to change
the name "Gnome" to "GNOME" so that it stands out in the search results.
Technically, GNOME is an acronym :).

Simos


signature.asc
Description: This is a digitally signed message part
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: newbie+ assamese translation

[Simos Xenitellis]

On Sat, 2007-05-05 at 13:05 +0530, Hriday Phukan wrote:
> this doesnot work as because they have not yet supported assamese.
> however there is hack in that we can work out the keymap by including
> extra characters as required. 
> 
> there is one more problem that i am facing is that i am unable to read
> the keyboard applet. my ubuntu and debian etch gnome keyboard applet
> is not displaying the characters in the correct format 

What do you mean by not "in the correct format". Is that a rendering
issue or an encoding issue? 

> and second question will true type font help in doing this ? i have
> located a true type font that could be used ?

You can easily install a Truetype font (Unicode) by simply dropping it
in ~/.fonts/. Or /usr/share/fonts/ for system-wide.

The system however does not guarantee that it will use that font to
display Assamese. Specifically, Assamese uses the Bengali script with
the addition of two glyphs (???) (Wikipedia). So, most probably a
Bengali font will override the Assamese you add.

So, what you do is simply select your own font at
System/Preferences/Font and will override all others. To verify your own
font is used, click Applications/Accessories/Character Map. Then, pick
the Bengali section. For each glyph simply right-click on them and it
will show you which exactly font the glyph came from.



The IndLinux.org website that Ihar mentioned, points to
http://luit.sourceforge.net for information on the Assamese language.
I have the impression it is not very active; it would to be good to find
a contact there.

At the Luit website, at the front page, there is a news item for the
'XKB keymap'. If you install the 'XKB keymap', you will be able to see
Assamese in the Keyboard applet of GNOME. If this keymap solves all
problems with Assamese writing, the luit team can send it "upstream" to
the keyboard project (xkeyboard-config) and then all newer distributions
will be able to write in Assamese simply by choosing the language.

The installation instructions for the keyboard map that are included are
not good ones; they do not help to integrate with GNOME Keyboard
Settings. 

1. You need to place the Assamese (as) file in /etc/X11/xkb/symbols/
2. Add in the keyboard database the Assamese layout, 
/etc/X11/xkb/rules/xorg.xml
3. Set the new layout at the Keyboard Applet. Set two layouts in total
(English, Assamese) as there might be some issues with three layouts.
Set the keyboard combination to switch between layouts; the default is
AltAlt which may not be good. Alt-Shift could be better.

Simos


signature.asc
Description: This is a digitally signed message part
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: newbie+ assamese translation

[Simos Xenitellis]

On Mon, 2007-05-07 at 02:44 +0530, G Karunakar wrote:
> 
> 
> On 5/6/07, Dewan Hrishikesh <[EMAIL PROTECTED]> wrote:
> thanks simos, i got some good idea of going about. why don't
> you document it out for some newbie to get a first hand
> information to start.
> 
> 
> You could add it here 
>  
> 
> http://www.indlinux.org/wiki/index.php/Assamese
> 
> Luit project hasnt had much activity over last 1.5yrs.. Perhaps
> someone else should come forward to take a lead role.

That's the place then to document the Assamese Linux support.

Dewan, from similar cases it has been found that it is more beneficial
for a new user to document himself as he assimilates new information.
Please fill in the Assamese page. For any help/comments, I am happy to
provide feedback. I am sure Karunakar will be able to provide input as
well, since he has extensive background in the localisation for Indic
languages.

All the best,
Simos




signature.asc
Description: This is a digitally signed message part
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Malaysian team

[Simos Xenitellis]

Στις 07-05-2007, ημέρα Δευ, και ώρα 19:14 +0100, ο/η Francis Tyers
έγραψε:
> Hi,
> 
> Mail for the Malaysian team co-ordinator is bouncing, does anyone have
> an alternate email address?

Try Sharuzzaman, http://cia.vc/stats/author/sharuzzaman
His address is sharuzzaman at gmail dot cοm.

His is currently involved in the KDE localisation though he should
probably know if there is anyone working on GNOME.

Simos


signature.asc
Description: Αυτό	 το	 σημείο	 του	 μηνύματος	 είναι	 ψηφιακά	 υπογεγραμμ	ένο
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: i18n of Turtle files for xesam project?

[Simos Xenitellis]

Στις 26-05-2007, ημέρα Σαβ, και ώρα 10:19 +0200, ο/η Mikkel Kamstrup
Erlandsen έγραψε:
> Hi Gnomers,
> 
> I also sent this mail to gnome-i18n a few days ago without any replies
> and the xesam project[1] badly needs feedback from enlightened people.
> 
> Here's the case. We need a way for describing our ontology and one of
> the runner up candidates is a subset of the Turtle syntax[2]. The
> files describing the ontology would then resemble: 
> 
> START_FILE
> 
> @prefix DC:   
> @prefix xesam:<
> http://freedesktop.org/standards/xesam#>
> @prefix : <
> http://freedesktop.org/standards/xesam_base#>
> 
> xesam:Audio.Composer
>   a   :field;
>   :of_type:string;
>   :has_parent DC:Creator;
>   :name   "Composer"@EN;
>   :name   "Komponist"@DA;
> 
>   :description"Audio composer".
> 
> xesam:Audio.Artist
>   a   :field;
>   :of_type:string;
>   :has_parent DC:Creator;
>   :name   "Artist"@EN;
>   :name   "Kunstner"@DA;
>   :description"Performer featuring in the recording"@EN;
> 
>   :description"Kunster der optræder på optagelsen"@DA.
> 
> 
> END_FILE
> 
> As you can guess the translations are marked with @ after the strings.
> 
> My question is : Will this cause problems or be a major hassle? How
> will it fit into the current translation workflow? 

Currently, the gnome i18n workflow can easily use .xml and .po files.
For other file formats there will be need for quite some extra work.
Thus, if you would like to use your proposed file format, you would need
to update http://svn.gnome.org/viewcvs/intltool/ Of course, contact the
maintainer of intltool first.

AFAIK, if intltool can parse your files, they will fit with the workflow
of GNOME.

Cheers,
Simos

> Cheers,
> Mikkel
> 
> PS: Please don't question the reasons for using Turtle, we already
> went through weeks of flame wars over this :-) Just the opinions or
> comments from an i18n point of view. Besides the choice is not final
> yet.
> 
> [1]: http://wiki.freedesktop.org/wiki/XesamAbout
> [2]: http://www.dajobe.org/2004/01/turtle/ 

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: i18n of Turtle files for xesam project?

[Simos Xenitellis]

Στις 26-05-2007, ημέρα Σαβ, και ώρα 14:57 +0200, ο/η Mikkel Kamstrup
Erlandsen έγραψε:
> 2007/5/26, Simos Xenitellis <[EMAIL PROTECTED]>:
> Στις 26-05-2007, ημέρα Σαβ, και ώρα 10:19 +0200, ο/η Mikkel
> Kamstrup
> Erlandsen έγραψε:
> > Hi Gnomers,
> >
> > I also sent this mail to gnome-i18n a few days ago without
> any replies
> > and the xesam project[1] badly needs feedback from
> enlightened people. 
> >
> > Here's the case. We need a way for describing our ontology
> and one of
> > the runner up candidates is a subset of the Turtle
> syntax[2]. The
> > files describing the ontology would then resemble: 
> >
> > START_FILE
> >
> > @prefix DC:   <http://freedesktop.org/standards/DC#>
> > @prefix xesam:<
> > http://freedesktop.org/standards/xesam#>
> > @prefix : <
> > http://freedesktop.org/standards/xesam_base#>
> >
> > xesam:Audio.Composer 
> >   a   :field;
> >   :of_type:string;
> >   :has_parent DC:Creator;
> >   :name   "Composer"@EN;
> >   :name   "Komponist"@DA; 
> >
> >   :description"Audio composer".
> >
> > xesam:Audio.Artist
> >   a   :field;
> >   :of_type:string;
> >   :has_parent DC:Creator;
> >   :name   "Artist"@EN;
> >   :name   "Kunstner"@DA;
> >   :description"Performer featuring in the
> recording"@EN;
> >
> >   :description"Kunster der optræder på
> optagelsen"@DA. 
> >
> > 
> > END_FILE
> >
> > As you can guess the translations are marked with @ after
> the strings.
> >
> > My question is : Will this cause problems or be a major
> hassle? How 
> > will it fit into the current translation workflow?
> 
> Currently, the gnome i18n workflow can easily use .xml and .po
> files.
> For other file formats there will be need for quite some extra
> work.
> Thus, if you would like to use your proposed file format, you
> would need 
> to update http://svn.gnome.org/viewcvs/intltool/ Of course,
> contact the
> maintainer of intltool first.
> 
> AFAIK, if intltool can parse your files, they will fit with
> the workflow 
> of GNOME.
> 
> Ok thanks for the tip :-)
> 
> How about the way fx .desktop files are handled? The translations are
> inlined in the .desktop files and that's also the way Turtle does it
> (see above example). So my concerns where about: 
> 
>  - I'm not keen on requiring the translators to understand
> yet-another-format, so I'm not keen on the translators having to
> resort to raw file editing
> 
>  - How hard would it be to make intltool extract the Turtle
> translation templates? Is there no way to tell intltool "use this
> external program to extract translation templates"? I've been browsing
> around the source and I can't find any clean way to extend it... 

Oh, intltool also understands .desktop files. From the README file
(http://svn.gnome.org/svn/intltool/trunk/README)

The intltool collection can be used to do these things:
 o Extract translatable strings from various source files (.xml.in,
   .glade, .desktop.in, .server.in, .oaf.in).
 o Collect the extracted strings together with messages from traditional
   source files (.c, .h) in po/$(PACKAGE).pot.
 o Merge back the translations from .po files into .xml, .desktop and
   .oaf files.  This merge step will happen at build resp. installation
   time.

I do not think it would be hard to extract the text from Turtle
translation templates. Just follow the example of the .desktop files
which should be very similar. You would need to code in Python a few
functions to extract/put back the translation messages. Is there some
Python module/code that understands the Turtle format (or the general
format that Turtle uses)?

Simos

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: About requesting help

[Simos Xenitellis]

Στις 15-06-2007, ημέρα Παρ, και ώρα 21:00 +0200, ο/η Fernando Apesteguía
έγραψε:
> On 6/15/07, Claude Paroz <[EMAIL PROTECTED]> wrote:
> > Le vendredi 15 juin 2007 à 20:23 +0200, Fernando Apesteguía a écrit :
> > > Hi all,
> > >
> > > I would like to know if this is a good place for asking some help with
> > > my small software project. I'm talking about finding translators.
> > >
> > > Is this the place?
> >
> > Maybe... If you're just looking for translators, give us the URL of your
> > project, and if it is interesting enough, you'll get plenty of
> > translators :-)
> 
> OK then ;)
> 
> The _small_ project is located at lkmonitor.sf.net. It's basically a
> system monitor like the gnome desktop's one that uses procfs.
> 
> The program is written in English and currently, Spanish, Croatian and
> Urdu are covered. I don't know exactly how to avoid collisions so if
> any of you wants to be the translations coordinator it would be very
> much appreciated :)
> 
> The pot file is available at lkmonitor.sourceforge.net/lkmonitor.pot
> I uploaded a screenshot to show a little of the 0.3 alpha version. It
> is available at lkmonitor.sf.net/Screenshot.png

To get the most out of the GNOME translation community for your
application, you would need to host the code on GNOME SVN.
In this way, lkmonitor would appear at 
http://l10n.gnome.org/languages/el/gnome-extras
and it would be easily visible to the translators of each team.

You have already made lkmonitor intltool-compatible, so the translation
statistics package will be able to pick it up.
After having the program hosted on GNOME SVN, the last step is to
request (=file a report on Bugzilla on package "damned-lies") to have
lkmonitor listed in
http://svn.gnome.org/viewcvs/damned-lies/trunk/releases.xml.in?view=markup

It might also make sense to use the GNOME Bugzilla for bug tracking.

Hope this helps,
Simos


___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Formatting lists of things

[Simos Xenitellis]

On 6/22/07, Marcel Telka <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 22, 2007 at 12:38:13PM -0300, Raphael Higino wrote:
> > Hey, Shaun. Good catch.
> >
> > First a silly note (and question too): AFAIK in English you'd just use
> > that last comma for disambiguation purposes, right?
> >
> > On 6/22/07, Shaun McCance <[EMAIL PROTECTED]> wrote:
> > > I've run into a localization issue in formatting DocBook,
> > > and I need some input from translators to decide how best
> > > to solve it.  Let's say I have a list of people's names.
> > > There could be any number of people.  I need to format
> > > this as inline text.  So in English, I'd do:
> > >
> > >   Tom and Dick
> > >   Tom, Dick, and Harry
> > >   Tom, Dick, Harry, and Sally
> > >
> > > The names, of course, don't get translated, but the
> > > commas and "and" should be.  So again, this time with
> > > parentheses around the potentially translatable parts:
> > >
> > >   Tom( and ) Dick
> > >   Tom(, )Dick(, and )Harry
> > >   Tom(, )Dick(, )Harry(, and )Sally
> > >
> > > If every language works exactly like English, then I
> > > can just mark three strings for translation: ", ",
> > > " and ", and ", and ".  But my guess is that they
> > > aren't all like English.
> > >
> > > So translators, please let me know hows lists of
> > > things are formatted in your language, including
> > > instructions on exceptions (i.e. in English, two
> > > elements are formatted differently than three or
> > > more, as above).
> >
> > In Portuguese (at least here in Brazil) our lists just wouldn't have
> > that last comma:
> >
> > Tom and Dick
> > Tom, Dick and Harry
> > Tom, Dick, Harry and Sally
>
> Same in Slovak (sk).

Modern Greek does not have the serial comma.

Wikipedia has an extensive article on serial commas,
http://en.wikipedia.org/wiki/Serial_comma

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Timestamps for PO file at l10n.gnome.org

[Simos Xenitellis]

Hi All,
As far as I know, damned-lies use intltool-update to update the po files
and place them at http://l10n.gnome.org/
intltool-update updates the header and specifically the fields

"POT-Creation-Date"
"PO-Revision-Date"

However, I do not see this in several examples, such as
http://l10n.gnome.org/module/gnome-media

Typical dates look like
"POT-Creation-Date: 2007-01-02 03:46+\n"
"PO-Revision-Date: 2006-07-02 23:07+0200\n"

We tend to advise new translators to use the PO files
from the statistic pages, therefore it's important to have
them updated.

Does the update fail or am I missing something?

Simos


___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: g-p-m: What does "quirk website" mean?

[Simos Xenitellis]

Στις 10-07-2007, ημέρα Τρι, και ώρα 13:34 +0700, ο/η Theppitak
Karoonboonyanan έγραψε:
> Hi,
> 
> In gnome-power-manager trunk:
> 
> #: ../src/gpm-notify.c:568
> msgid "Visit quirk website"
> 
> >From the source, it seems to appear on hibernation failure.
> But where does it point to, so we can find appropriate
> translated term for it?

The file gpm-notify.c is at 
http://svn.gnome.org/viewcvs/gnome-power-manager/trunk/src/gpm-notify.c?view=log
(click on "view" to see the content of the file).

The website then is
http://people.freedesktop.org/~hughsient/quirk/

It refers partly to the blog post at
http://hughsient.livejournal.com/29730.html
Quirks refer to strange/weird/undocumented behaviour of hardware.
Because the manufacturers do not provide the necessary information for
non-FOSS software support, it is up to the users to supply the info by
following the procedures outlined in the "Quirks website".

Simos


___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Uninformative string in accerciser

[Simos Xenitellis]

Στις 17-07-2007, ημέρα Τρι, και ώρα 16:21 +0200, ο/η Daniel Nylander
έγραψε:
> (me is now back from 2 sunny and wet (the bar) weeks in Greece)
> 
> 
> Can someone help me find out what this string in accerciser means?
> 
> #: ../plugins/interface_view.glade.h:23
> msgid "C"
> msgstr ""
> 

The message comes from 
http://svn.gnome.org/viewcvs/accerciser/trunk/plugins/interface_view.glade?view=markup
Do a search for something like ">C<" and you will get 


True
0
C
True





It is part of something like

Locale: C

and while the label "Locale" is translatable, the result ("C") is
determined when you run the program.

Just talked with Eitan and apparently this message should not have been
marked as translatable. 

Simos

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

MO files not optimised enough (esp. en_GB, en_CA, etc)

[Simos Xenitellis]

Hi All,
It is common in translation teams when a message does not need/require
translation to simply copy the "msgid" content to "msgstr". For example,

msgid "GConf"
msgstr "GConf"

This is quite common for the locales en_GB, en_CA where the vast
majority of the messages remain the same.

The problem arises from the fact that when compiling those PO files into
MO files (with "msgfmt"), the copied messages are included, contributing
to an increased size of the file on disk, and also in memory when the
application is loaded. The issue is, those copied messages could have
been ommited entirely in the MO file as the running application does not
need them (it can use the message text that is already included in the
executable).

I blogged about this at
http://blogs.gnome.org/simos/2007/07/23/important-mo-file-optimisation-for-en_-locales-and-partly-others/

I sent a bug report at the gettext bugs email address. If anyone knows
of an alternative way to get in contact with the gettext developers,
please tell me.

Simos


___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: confusing string in divifund

[Simos Xenitellis]

Στις 26-07-2007, ημέρα Πεμ, και ώρα 10:32 -0400, ο/η Claudio Saavedra
έγραψε:
> On Thu, 2007-07-26 at 13:05 +0100, Simos Xenitellis wrote:
> > "From your budget and the amount you've already spent, you will need
> > to
> > have saved" 150 euros.
> > 
> > It may be an issue for some languages that the object is not always at
> > the end of the sentence. 
> 
> It is an issue. At least in German (if I still remember German grammar)
> it's tricky to translate.
> 
> Looking the code it seems the complete sentence is something like
> 
> "From your budget and the amount you've already spent, you will
> need to have saved %s by the date %s" ,
> 
> so it's even trickier.
> 
> Instead of trying to be as creative as possible in order to translate
> such unfriendly strings, you should file bugs. I've done this in the
> past a couple of times, developers have always been friendly and fixed
> the issues.

This is a good example to try to suggest here how it should be tackled,
then document on live.gnome.org for developers to reference.
Please be constructive on the following:


Let's assume that we have the following message and we want to make it
possible to translate in different languages, including languages that
follow a different order from "subject verb object".

"From your budget and the amount you've already spent, you will need to
have saved %s by the date %s"

In this case we can use "positional arguments" as described in 
http://www.gnu.org/software/gettext/manual/gettext.html#c_002dformat

The above message is then converted in the source code to 

"From your budget and the amount you've already spent, you will need to
have saved %1$s by the date %2$s"

Another example is 
from
"You run for %d minutes along the %s route with team %s."
to
"You run for %1$d minutes along the %2$s route with team %3$s."

Sometimes it is good to break messages in smaller parts. However, in
this example it is better to leave as a single message, due to the
sentence structure.


How does that look like?

Simos Xenitellis



___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: confusing string in divifund

[Simos Xenitellis]

Στις 26-07-2007, ημέρα Πεμ, και ώρα 13:48 +0200, ο/η Sílvia Miranda
έγραψε:
> Hi,
> 
> I don't know if theese is the right place to ask for help when we don't
> understand a string... I hope it is!
> 
> We're translating divifund into Catalan. I found this string which I
> don't really understand:
> 
> #: ../DivifundClass.py:1830
> msgid ""
> "From your budget and the amount you've already spent, you will need to
> have saved"
> 
> Can anybody explain what it means? I think it's confusing... I wanted to
> report it in Bugzilla (we are supposed to do it, aren't we?) but I don't
> know under which category I should file it. Is it in Translations?

Hi Silvia,
Andre posted on p.g.o some instructions on this. I suppose he is reading
the list as well,
http://blogs.gnome.org/aklapper/2007/07/25/220s-internationalization-guadec-results/
He proposes to file a bug report on the specific project and add the
"l10n" keyword. That is not the product "l10n" but the textbox for
"Keyword" on the bug report page.

Personally I find this a bit cumbersome and was wondering if maintainers
would accept translator comments directly (if they are CC:ed to this
list).

The message above is supposed to be cut off, as in

"From your budget and the amount you've already spent, you will need to
have saved" 150 euros.

It may be an issue for some languages that the object is not always at
the end of the sentence.

Simos


___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

library.gnome.org questions (broken markup?, generation date)

[Simos Xenitellis]

Hi All,
I think library.gnome.org is amazing. It helps a lot at least to
motivate new users.

I have two questions:
a. It looks to me that some mark-up is not closed properly. Therefore,
in normal paragraph text you get the annoying underline/blue colour
feature as if an http://library.gnome.org/users/gnotravex/2.19/usage.html.el
(second and third para of 2.1.1, first para of 2.1.2)
http://library.gnome.org/users/file-roller/stable/file-roller-modify-contents.html.de
(many locations)
b. For Greek, the Keyboard Indicator Manual has been translated fully
and DOC_LINGUAS has "el" in it,
http://svn.gnome.org/viewcvs/gnome-applets/trunk/gswitchit/help/Makefile.am?view=markup
However, at
http://library.gnome.org/users/index.html.el
it appears are untranslated.
It shows fully translated at
http://l10n.gnome.org/languages/el/gnome-2-20
On the same page there is no warning of a screw-up with the markup of
the translation.
I think it would be good to have a generation date for the HTML files,
either towards the footnote, or in the header of the HTML document.
Would that help?

Simos


___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: library.gnome.org questions (broken markup?, generation date)

[Simos Xenitellis]

On Mon, 2007-08-20 at 14:09 +0200, Frederic Peters wrote:
> I wrote:
> 
> > I looked at the Tetravex problem and the problem lies in empty 
> > tags used as anchors, such as .
> > 
> > Interestingly this doesn't happen on my computer, which is using
> > revision 981 of gnome-doc-utils; Shaun, what change could have caused
> > this ?
> 
> It may actually be caused by the libxslt version installed on
> library.gnome.org; currently at 1.1.17 while latest release is 1.1.21
> (note I also tested 1.1.19 on Etch and it works there).

It appears that this issue (anchors) has been partially fixed. Now it
appears as
http://library.gnome.org/users/gnotravex/2.19/usage.html.en
which shows multiples of the figures. The HTML code looks like




 

Simos

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Count of localised GNOME desktops

[Simos Xenitellis]

Hi All,
I was wondering if there are stats of the number of localised GNOME
desktops per language, as used by distributions.
This would help to direct localisation efforts and get more support.

I think there was a discussion relating to this for Fedora 7, which I do
not know if they collected information for localisations.

Simos

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Count of localised GNOME desktops

[Simos Xenitellis]

On Tue, 2007-08-28 at 02:00 +0100, Simos Xenitellis wrote:
> Hi All,
> I was wondering if there are stats of the number of localised GNOME
> desktops per language, as used by distributions.
> This would help to direct localisation efforts and get more support.
> 
> I think there was a discussion relating to this for Fedora 7, which I do
> not know if they collected information for localisations.

Here are the stats for Fedora,
http://smolt.fedoraproject.org/stats

At the end of the page there is a break-down on locale. Of course there
are the cases of users that installed the distro but chose the default
locale. Considering that the default desktop environment is GNOME, this
should translate in GNOME Desktops.

In the case of Ubuntu I do not think there is an explicit process to
collect these stats. One could possibly extra such information from
accesses for updates, either to security.ubuntu.com (all systems,
whichever their locale) or to the localised CC.archive.ubuntu.com, where
CC is the country code. In either case, the locale information is not
recorded.

Simos


___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Pashto team update (Was: Re: Pashto - coordinator should be changed!)

[Simos Xenitellis]

Hi,

There are some existing threads on Pashto/Pushto, at
http://mail.gnome.org/archives/gnome-i18n/2006-September/msg00099.html
http://mail.gnome.org/archives/gnome-i18n/2006-August/msg00199.html
http://mail.gnome.org/archives/gnome-i18n/2006-September/msg00020.html
For the official name of the language, see
http://xml.coverpages.org/iso639a.html (it now says either Pashto or
Pushto)

If you want to become team coordinator for Pashto, you have to read the
next steps carefully. 
The current coordinator listed for Pashto is Ismail Maskani,
http://l10n.gnome.org/languages/ps
His e-mail address is at 
http://l10n.gnome.org/people/x-ismailmaskani

To change the Team Coordinator, the instructions are listed at
http://live.gnome.org/TranslationProject/CoordinationActions
You need to perform Step 1 (send e-mail to this list that you are
interested to take over, AND also cc: the Ismail).

The responsibilities of a team coordinator include
http://live.gnome.org/TranslationProject/TeamCoordinatorResponsibilities

Good luck,
Simos

On Mon, 2007-09-03 at 00:20 -0700, zabeeh khan wrote:
> Dear brother,
> Someone has added the Pashto in the languages list, but he is
> non-responsive I have sent him mail, but he doesn't reply. So we want
> to take coordination work, I mean we are a company called Pakhtosoft,
> we develop software and OS for Pashto. And now we want to translate
> the GNOME to Pashto. We will be willing to do that very well. That
> person has not done anything, everythings status is zero. So we want
> to be the coordintor and translate GNOME to Pashto. I tried much to
> contact him, but he doesn't answers. 
>  Thanks,
>   Pakhtosoft
> www.pakhtosoft.com



___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Argh.. Novell people imports external translations again

[Simos Xenitellis]

On Sat, 2007-09-15 at 18:24 +0200, Daniel Nylander wrote:
> Daniel Nylander skrev:
> > This is not the first time I have seen Novell people doing translation
> > imports into GNOME GTP controlled applications.
> > 
> > This time it is gnome-main-menu that has been violated.
> 
> I did notice that the reported string freeze violation yesterday in
> gnome-control-center (lislab) is part of the same issue here.
> 
> 18 translations in gnome-main-menu has been imported and Last-Translator
> has been set to "Novell Language <[EMAIL PROTECTED]>" (at least for
> Swedish). This pisses me off seriously.

What we have here is that user "jimmyk" does these commits. Can you get
hold of him to investigate what has happened?
An overview of jimmyk's recent commits can be seen at 
http://cia.vc/stats/author/jimmyk
His profile, 
http://guadec.org/user/203

Simos


___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Translators for FOSS project

[Simos Xenitellis]

On Tue, 2007-10-09 at 14:37 +0200, Wouter Bolsterlee wrote:
> 2007-10-08 klockan 23:09 skrev Joaquim Rocha:
> > We now wanted the project to be translated to other languages and that's 
> > why I am writing this email.
> > [snip]
> > So, if anyone is able to help us, please check the project webpage:
> > http://bluepad.sourceforge.net
> > 
> > and send us an email. It won't give much trouble as there are few lines 
> > to be translated.
> 
> Your code does not seem to use intltool/gettext but some sort of
> non-standard i18n system. This is far from desirable since a) it is non
> standard and b) causes problems for lots of languages.

To figure out how to make BluePad friendly to GNOME localisation, you
can see other pyGTK projects and compare the code.
Examples include
http://svn.gnome.org/viewvc/gimmie/trunk/
http://svn.gnome.org/viewvc/accerciser/trunk/

BluePad is really cool. If you think you can manage the effort to get it
GNOME-friendly, it could be added to http://l10n.gnome.org/module/
This would also require to move the source to GNOME SVN.

Hope this helps,
Simos


___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: i18n blog?

[Simos Xenitellis]

On Mon, 2007-12-10 at 23:38 -0500, Thomas Thurman wrote:
> I've found it useful in the last few weeks to have a project blog for
> Metacity (). I wonder whether it
> would be useful for the i18n effort as a whole to have a shared
> project blog where people could post about the challenges different
> people have to face and what they're doing to overcome them. Maybe
> it's just a solution looking for a problem, I don't know.

You mean to create something like a GNOME L10n Planet,
http://planet.l10n.gnome.org/ 
that aggregates blogs from the members of the tranlation teams?

Simos


___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Nepali Translation team coordinator unresponsive

[Simos Xenitellis]

I think the nplinux.org website is down, so their e-mail could also be
affected.

Mukesh, do you have another contact to the Nepali team? Google can help
you here.

I cc: Subir in case he can help.

Simos

On Sat, 2007-12-15 at 14:10 +0100, Claude Paroz wrote:
> Le vendredi 14 décembre 2007 à 08:29 +0545, mukesh modi a écrit :
> > Hello,
> >I have been attempting Nepali translation of few gnome files. I
> > tried to contact the team coordinator of the Nepali translation team.
> > But, the mail I sent him at [EMAIL PROTECTED] bounced. That is to say,
> > the coordinator is unresponsive.
> >Hence, I request you to take necessary action to ensure the
> > translation task continues.
> 
> If the current coordinator is unresponsive, that may mean that Nepali
> needs a new coordinator.
> 
> Meanwhile, you can continue to submit translations to GNOME Bugzilla, as
> you already did in #503532. If nothing happens after 2 or 3 weeks, don't
> hesitate to ask on this list for someone to help commit your work.
> 
> Thanks for your contribution.
> 
> Claude
> 
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-i18n

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Rethinking "Supported language"

[Simos Xenitellis]

Wouter Bolsterlee wrote:
> Dear all,
>
> Currently, http://www.gnome.org/i18n/ states that a language is officially
> "supported" if 80% of the PO files is translated. I think this measure is no
> longer valid for modern Gnome releases, because of the 'Development Tools'
> suite. It contains the following modules:
>
>   - accerciser
>   - anjuta
>   - devhelp
>   - gdl
>   - glade3
>   - gnome-build
>
> The problems I see are:
>
>   1.  None of the programs are intended for regular users. Therefor it's
>   unreasonable to treat them as such when deciding whether a translation
>   is officially "supported".
>   2.  Developers will generally use those programs in English anyway. I dare
>   to say that there is not a single Dutch speaking user that wants to a
>   program such as Glade or Accerciser in Dutch. Translating lots of
>   strings that will never be visible to users is just a waste of time.
>   Note that most translation teams have very limited resources.
>   3.  Since those programs contains more than 3000 strings (3144 according
>   to my last count), they account for a substantial part of the total
>   number of strings (somewhere in the around 40.000). This very
>   negatively impacts the percentage indicating the translation coverage.
>
> My proposal is: only use the modules from the developer platform, desktop
> and administration tools when calculating the 80% coverage statistic (i.e.
> all module sets but the developer tools).
>
> What do you think?
>   
Whether a language is deemmed as supported or not is a GNOME thing, a 
piece of information to get into the release notes. As far as I know, 
the distributions (Ubuntu, Fedora) will create language packs for any 
language, no matter what is the degree of translation completeness.

I feel too it makes sense not to count the dev group of modules in 
figuring out whether translations are completed by 80% or more.

Simos

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Rethinking "Supported language"

[Simos Xenitellis]

Ihar Hrachyshka wrote:
> 2008/2/19 Mişu Moldovan <[EMAIL PROTECTED]>:
>   
>> "Ihar Hrachyshka" <[EMAIL PROTECTED]> a scris:
>> 
>>> 2008/2/19 Mişu Moldovan <[EMAIL PROTECTED]>:
>>>   
 I'm not against translating them, it's just that they are of no use
 to regular users.
 
>>> Who are these regular users, hum? Am I not "regular"? If "regular"
>>> users don't need these tools then - just drop them! If they are there,
>>> in official release sets then it's what our users (newbies and
>>> photographers aren't better or smth then programmers) need.
>>>   
>> I'm not against releasing them either... Just don't count their
>> localizations when deciding which language are supported and which are
>> not because most of the users do not use them at all.
>> 
> Most users don't use accessibility features provided by GNOME (and
> here are > 1000 messages!). Most users don't use "zenity" rapid
> scripting system and our Windows remote connectivity tools for GNOME.
> Is it the reason not to count them as a 100% GNOME component?
>   
As I mentioned earlier, the "Supported language" is for use in the 
release notes only.
By not counting the devel tools, we lower the barrier for new languages 
to get the "supported" badge.
We already do something similar, but not counting the documentation in 
the %80 barrier.

The proper question then, would be: Is it a significant effect to your 
team and
your local marketing of GNOME if you are in the "supported language" group?

The languages that could take advantage from this include (70%-79% in
http://l10n.gnome.org/releases/gnome-2-22 )

Latvian
Basque
Hindi
Bengali (India)
Malayalam
Albanian
Welsh
Assamese
Hebrew
Marathi
Indonesia
Bengali
Romanian

If you can speak up for these languages, then it would make sense to 
make the 80% adjustment.

Otherwise, it would be better to spend the time translating ;-)

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Some questions for nice translations

[Simos Xenitellis]

Hi,
To find the correct branch, visit the l10n statistics page with the
program (for gtranslator it would be
http://l10n.gnome.org/languages/el/gnome-extras) and place the mouse
pointer on the name of the package.
A tooltip will appear that shows the correct branch, gtranslator_1_1_8.

Simos

2008/2/19 Yannig MARCHEGAY <[EMAIL PROTECTED]>:
> Hello,
>
> 1/ I was told a few days ago that I didn't translate gtranslator in the
> correct branch. Have someone done a script or a webpage where I could
> quickly see in which branch I should commit my translations?
>  2/ inttltool-update does not work for docs po file. Is there a way of
> updating them easiliy (instead of always downloading the pot file)?
> 3/ Just in case: I often make some changes to quite a lot of po file before
> I commit them. Any way to batch-add the info in the ChangeLog file and
> batch-commit all these files?
>
> Thanks a lot,
> Yannig
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-i18n
>
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Friulian Language: In Gnome 2.22?

[Simos Xenitellis]

[EMAIL PROTECTED] wrote:
> I'm working very well (but not very fast!) to translate
> GNOME in my language. Is possible to find my language in
> the next release of GNOME, or I must wait GNOME 2.24
> (hope to translate another files)?
> Friulian Language is on 3% translated...
> Massimo
>   
My take on this is that you should translate as much as you feel it is 
possible.
It is nice to focus first on applications that have the most visibility 
to your users.

A language may be marked as supported or unsupported in the GNOME 
Release Notes,
however it is up to each distribution to choose whether they will 
include any partial translations or not.

My understanding with Ubuntu (and possibly Fedora, and others) is that 
they include anyway those translations.

To activate language support for a specific language, you go to 
System/Administration/Language Support, tick the language(s) of your 
interest and press Apply. Logout, choose Friulian, and log in again.

I noticed that in my distribution there is no entry for Friulian in the 
Language Support list. You may want to investigate how this list is 
maintained (for example, if there are any translations at all, or 
whether in Debian the language has been registered; for the case of Ubuntu).

Hope this helps,
Simos Xenitellis
http://blogs.gnome.org/simos/
 
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: new language: UPPER SORBIAN

[Simos Xenitellis]

Thomas Krauße wrote:
> Hello all-together,
>
> I want to found a team for a new language in GNOME. My chosen language
> is Upper Sorbian. It is the language of the Sorbian minority in the
> eastern part of Germany.
>
> - see  -
>
> Originally I'm German but within my relationship to my Sorbian
> girlfriend I learnt Sorbian quite well and together with her help it
> will be possible for me to perform correct translations. I'll also try
> to establish a contact with Eduard Werner, who provided the Sorbian
> translation for the KDE desktop.
>
> What's to do to found a new language team? How can I translate the items
> of GNOME? Is there any documentation what's to - and what not ;) - or
> any kind of how-to? Thank you very much for your help.
>   
Hi Thomas,

Welcome to GNOME Localisation!

There is a page with instructions on new teams at
http://live.gnome.org/TranslationProject/JoiningTranslation

Go through it and if there is any questions, feel free to ask the list.

Simos
http://blogs.gnome.org/simos/

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Adding policykit-gnome to damned-lies

[Simos Xenitellis]

Hi All,
I noticed that policykit-gnome,

Homepage: http://hal.freedesktop.org/docs/PolicyKit/
  http://hal.freedesktop.org/docs/PolicyKit-gnome/
svn/git/bzr/...: http://gitweb.freedesktop.org/?p=PolicyKit.git;a=summary
 
http://gitweb.freedesktop.org/?p=users/david/PolicyKit-gnome.git;a=summary
Tarballs: http://hal.freedesktop.org/releases/
Proposal on d-d-l: 
http://mail.gnome.org/archives/desktop-devel-list/2007-October/msg00237.html

is not in 

http://l10n.gnome.org/languages/el/freedesktop.org

Is it available somewhere else that I did not see?

PolicyKit-gnome is a default package in Ubuntu and probably elsewhere.

Simos
 


___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Application categories translations in library.gnome.org

[Simos Xenitellis]

Theppitak Karoonboonyanan wrote:
> Hi,
>
> I wonder where the translations for application categoreis, such as
> "Desktop", "Accessibility", "Accessories", etc. in GNOME Library
> Users page [1] come from.
>
>   [1] http://library.gnome.org/users/
>
> For Thai page, they appear to be from very old versions of yelp or
> gnome-menus translations. (It must be yelp, I suppose.)
> How can I update them to newer version?
>   
They come from this translation,
http://l10n.gnome.org/module/library-web

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Can anyone tell me where should I send the translated file of xdg-user-dirs.HEAD.po ??

[Simos Xenitellis]

Vikram Vincent wrote:
> Zabeeh khan wrote:
>   
>> Can anyone tell me where should I send the translated file of 
>> xdg-user-dirs.HEAD.po ?? I visited the link which is there when 
>> downloading it but there is nothing about how to send it and where to 
>> send it. Please someone guide me or send it yourself? I will send you 
>> the file if you need it.
>> 
> https://bugs.freedesktop.org/
>   
You need to file a bug report including your translation. The bug report 
should be similar to
https://bugs.freedesktop.org/show_bug.cgi?id=14565

To make it easier for you, there is an option on that page called "Clone 
this report", that you can use to prefill the new report fields.

Simos


___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Improving things for translators (part 2)

[Simos Xenitellis]

Leonardo Fontenelle wrote:
> Em Seg, 2008-03-17 às 01:44 +0100, Robert-André Mauchin escreveu:
>   
>> In the same vein of improving things for translators, I would like to
>> reopen the subject of Transifex, an improvement of Damned Lies made by
>> Dimitri Glezos for the Fedora Project.
>> 
>
> What are we discussing here? A tool for GNOME, for any upstream project,
> or for distributions as well? The feature set will depend on this
> decision.
>
> I already read many ideas on rewriting and extending different tools:
> damned-lies, transifex, vertimus and pootle. IMVHO this should be
> decided based on convenience: Which one is closer to the desired feature
> set? Which one is more extensible?
>
> Maybe another relevant question is: Which one is more actively
> developed? Everyone is very busy, but the new translation
> tracker/committer would need at least one lead developer.
>
> What do you think?
>   
My preference would be for a simple command line tool that is described at
http://blogs.gnome.org/simos/2008/03/03/designing-a-command-line-translation-tool-for-gnome/

At this stage of translation we (local team) have the issue of managing 
the overall quality of the translations, making sure that terms are 
translated uniformly across packages.

Simos

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Translation hackerthon

[Simos Xenitellis]

Danishka Navin wrote:
> Hi All,
>
> Sinhala (si-LK) community will be conducting a translation hackerthon 
> on 29th and 30th March 2008.
> Appreciate your valuable ideas and major areas we should play around.
I think the common option here is to put everyone in a lab and install 
Pootle on a local server.
Translation allocation takes place though Pootle, using a web browser.

If there is a big blackboard/whiteboard in the lab, use it to write down 
common terms and their translation, so people can come back to it while 
translating. If you already have a list of terms and their translation, 
you can also use the Terminology features in Pootle (the relevant terms 
and their translation appear on the web page).

Dwayne (South African languages), who develops Pootle, has done several 
translate-a-thons. You may want to send him a personal e-mail.

An ambitious goal would be to target GNOME Desktop section from 
http://l10n.gnome.org/languages/si/gnome-2-22
GNOME 2.22 is out, but 2.22.1 is out in early April. You may be able to 
make it for Ubuntu 8.04, and also for the next Fedora.

If you have an Ubuntu 8.04Alpha system available, you can translate and 
also demonstrate to the team. It helps with moral to see the work in 
action. Also it helps to have translators run the application that they 
are translating to make the translations more suitable/refined.

The purpose of the translate-a-thon would be to have adequate quality 
full translations that you can review later.

It would be great to write up a report after the event takes place. It 
will be helpful to the other teams.

Good luck,
Simos

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Improving things for translators (part 2)

[Simos Xenitellis]

Kenneth Nielsen wrote:
>
> I use jhbuild to check out all the source code (translations included)
> of a release, e.g. gnome-2-22. That way I don't have the risk of
> committing to trunk a translation without noticing the module
> branched.
> It's not smart, but it make my life easier.
>
>
> I still don't really undestand this. But maybe it is not relevan here. 
> I also check out the source code for the modules (only with directly 
> svn in stead) I have to commit to, but that is because I need to be 
> able to run the intl-tools on them. But what I don't understand is the 
> stuff you write about keeping track of braches. damned lies tells you 
> which branch is targeted, then simply commit to that, copy the 
> translation to trunk and run intl-update and commit that as well. I 
> don't see the that as such a big burden that any team can't have one 
> or two people that know how to do that.
The benefit with using jhbuild is that you can set it up and simply 
write a single command that looks  like "jhbuild build gnome-2-22", let 
the computer run in the night, and in the morning you will have all the 
correct SVN checkouts for the packages you see in damned-lies.
 You can then enter the po/ subdirectories and run intltool-update, and 
you can even run this cutting edge gnome to verify your translations.

Having a system such as 
http://blogs.gnome.org/simos/2008/03/03/designing-a-command-line-translation-tool-for-gnome/
would be like having a cut-down version of "jhbuild" that can do the 
work with 10-15MB of data instead of >1GB.

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Kazakh Coordinator Not Responding

[Simos Xenitellis]

Gizat M. wrote:
> Dear GNOME staff,
> I am from Kazakhstan and had been using GNU/Linux for over two months 
> now and will never switch to other OS again!
> Because I love it so much, I'd like to spread it among my Kazakh 
> people. And I am eager to contribute in making a Kazakh GNOME.
> However, the current coordinator assigned for the Kazakh team is not 
> responding, that is his email is not valid, it doesn't exist. I can't 
> reach him and there's no advances in translation (zero modification 
> had been made).
> How can I resolve this issue? Can I become a coordinator and start 
> translating GNOME?
> Sincerely,
> Gizat Makhanov.
Hi Gizat,

Thanks for your interesting in localising GNOME in the Kazakh language.

To become the coordinator for Kazakh, please see the section "There is 
already a non-responsive coordinator"at
http://live.gnome.org/TranslationProject/StartingATeam

Here is his registration of the Kazakh team in 2004,
http://mail.gnome.org/archives/gnome-i18n/2004-December/msg00020.html

I did some searching for Amrenov. His nickname is "arruah", and 
apparently his has been active in Ubuntu Rosseta. His profile,
https://launchpad.net/~arruah
shows an updated e-mail address which I cc: as well.
He also has a blog, which shows that he is active in open-source, but he 
has neglected to update the details at GNOME Translation.

Ubuntu allows to translate GNOME on their own servers, and it appears 
that Amrenov has done a little work there,
https://translations.edge.launchpad.net/~arruah/
However, none of these translations have been added back to GNOME (this 
has to be done manually).

I am cc:ing Amrenov, as evidence that a notification e-mail has been 
sent to his e-mail account.
Amrenov, if you are reading this, please reply.

Kazakh localisation is very important for GNOME.
It is very important for both of you to talk it over and make an active 
Kazakh GNOME localisation team.

Simos Xenitellis
Greek localisation team
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Page shows MySQL password on http://l10n.gnome.org/module/libgda

[Simos Xenitellis]

Hi,
I am forwarding the e-mail to the [EMAIL PROTECTED] mailing 
list, which deals with these issues.

Cheers,
Simos

Vivien Malerba wrote:
> Hi!
>
> please forgive me if this message is out of subject for this list, but
> I could not find a better contact.
>
> This morning I tried to get the translations status of Libgda and I
> got a page full of Python errors, and at the bottom was the name of
> the MySQL database with the username and passwords to use. I guess
> this is not a very good idea... I can send a screenshot on request.
>
> I just reloaded the page and the normal page was displayed...
>
> Regards,
>
> Vivien


___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: pango and gucharmap

[Simos Xenitellis]

Christian Persch wrote:
> Hi;
>
> the new strings would be these unicode script and block names:
>
>   
>>  +msgid "Sundanese"
>>  +msgid "Lepcha"
>>  +msgid "Ol Chiki"
>>  +msgid "Cyrillic Extended-A"
>>  +msgid "Vai"
>>  +msgid "Cyrillic Extended-B"
>>  +msgid "Saurashtra"
>>  +msgid "Kayah Li"
>>  +msgid "Rejang"
>>  +msgid "Cham"
>>  +msgid "Ancient Symbols"
>>  +msgid "Phaistos Disc"
>>  +msgid "Lycian"
>>  +msgid "Carian"
>>  +msgid "Lydian"
>>  +msgid "Mahjong Tiles"
>>  +msgid "Domino Tiles"
>> 
Thanks. I'ld like to add here some q n a.

Q. What's the effect if these scripts are included but happen to remain 
untranslated in many of the languages?
A. When the user starts up Character Map, she is likely to see these 
script names in the
Script list. This is due to sorting, english letters appear on top of 
other scripts such as Cyrillic, Greek, Arabic, etc. From the above list, 
it's going to be about a dozen entries.

Q. What's the effect if these scripts are not included in gucharmap?
A. If the user installs any of the updated fonts, she will not be able 
to view any of the new characters. This would be a defect, for about 60% 
of the users (using en_US locale, source: smolt)

Q. Anyway, are there fonts available for these new Unicode scripts?
A. For the Ancient Greek-era scripts, there are
http://*greek**fonts*.teilar.gr/  Covers five of the new Unicode blocks.

At the same place, there are fonts for things like Mahjong and Domino 
tiles, at least seven blocks in total.
These fonts have not been packaged yet, so a user would need to install 
by hand.

DejaVu will release a new scheduled version with some of the new 
characters (for example, characters in the Basic Greek block).

I suspect there are other fonts in preparation.

Personally, I would like the new scripts be included, even considering 
the fact they will eventually remain untranslated for some languages, in 
GNOME 2.22.1. My reason is the issue of correctness, to be able to view 
characters for these new fonts.

Simos

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: start a new translation team

[Simos Xenitellis]

Mostafa Daneshvar wrote:
> On Yek-shanbe 25 Farvardin 1387 17:59:14 Andre Klapper wrote:
>   
>> hi mohammad,
>>
>> Am Sonntag, den 13.04.2008, 17:06 +0430 schrieb Mohammad Foroughi:
>> 
>>>  I want to start a new translation team for Persian language. You me say
>>> that there is already a team for persian, yes I know thatm bust it is
>>> about 2 years that the old team did not act any usefull action. If you
>>> take a look at their web site (http://www.farsiweb.ir/wiki/Main_Page),
>>> just at the very buttom of the page, you can see that it's last update
>>> is: October 2006!
>>>   
>> did you contact the iranian team leader already by email (see
>> http://l10n.gnome.org/languages/fa/ )?
>> the gnome translation project prefers such problems to be discussed and
>> solved within the language teams themselves if possible, but of course
>> that's not possible if you don't receive an answer from them... :-)
>>
>> andre
>> 
>
> Dear Mohammad,
> If you've made some Persian translation, you can ask other members to commit 
> them for you. 
>   
What Andre wrote is the correct way to go forward. Contact the current 
maintainer for the language, and ask your questions. To assume what the 
answer will be and what not, is plain silly.

Simos

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: translating numbers

[Simos Xenitellis]

O/H Khaled Hosny έγραψε:
> I'm going to repeat what Djihed said, in Arabic we either use Arabic or
> Arabic-Indic numbers according to locale. Now if we have a string "1" or
> "2" and so on, we won't be able to translate it as people in Egypt (and
> other Arabic counteries to the east of it) want "١" and "٢", while
> others want to keep it "1" and "2". 
>
> By using place holder, %d, we can translate it %Id and let the locale
> definition decide which system to be used.
>   
Daniel, you put then something like

countdown = 3;
while (countdown>=0) {
   /* TRANSLATORS: This is the countdown number when taking the photograph.
* If you leave as is (that is, %d), it will show 3, 2, 1, 0. To 
enable to show the numbers in your
* own language, use  %Id instead.
*/
   show_on_screen("%d");
}

Gettext will take the comment and add it in the PO file for the 
translators to see.

Simos
> On Fri, Apr 25, 2008 at 07:27:17PM +0200, daniel g. siegel wrote:
>   
>> using "1", "2", "3" as strings makes more sense to me, as we wont have
>> any other numbers. i commited it to trunk.
>>
>> thanks!
>>
>> daniel
>>
>> On Wed, 2008-04-23 at 21:31 +0100, Djihed Afifi wrote:
>>  <في ر، 23-04-2008 عند 22:29 +0200 ، كتب daniel g. siegel:
>> 
 hi!

 in cheese we got a nice countdown widget, which just counts down from 3
 to 1 and then shows a small camera. those three strings ("1", "2", and
 "3" are not translated). should i make them translatable?

 at least i think, there are some people, who do not use arabic numbers.

 
>>> Hi!
>>>
>>> Please work it out using variable placeholders, i.e %d and a comment.
>>>
>>> That way, we, at the Arabic team (we use both Arabic and Hindu numerals
>>> for different locales) could just use %Id and the application will
>>> display the right numerals upon reading the locale. 
>>>
>>> If you use 1, 2, etc verbatim we will just copy them and nobody will get
>>> the benefit.
>>>
>>> Djihed
>>>   

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: translating numbers

[Simos Xenitellis]

O/H daniel g. siegel έγραψε:
> oh.. i got you wrong ;)
>
> its fixed now in svn
>   
http://svn.gnome.org/viewvc/cheese/trunk/src/cheese-countdown.c?r1=685&r2=687&sortby=date

Thanks!

Another issue that I notice is that you specify the font "Bitstream 
Charter", as the font for the countdown text. This font supports Latin 
characters only. If the numbers are in a different language, typical 
font substitution will take place so it should work in this specific 
case. However, in the general case it is not a good idea.

An alternative is to use "Sans" (or "Serif"), which are virtual fonts, 
and pick the appropriate font explicitly through the configuration files 
in /etc/fonts/conf.d/
For example, the "serif" font for Thai characters is the Norasi font 
(that's what my Ubuntu configuration files say).

Hope this helps,
Simos
> thanks!
>
>
> On Fri, 2008-04-25 at 21:34 +0300, Khaled Hosny wrote:
>   
>> I'm going to repeat what Djihed said, in Arabic we either use Arabic or
>> Arabic-Indic numbers according to locale. Now if we have a string "1" or
>> "2" and so on, we won't be able to translate it as people in Egypt (and
>> other Arabic counteries to the east of it) want "١" and "٢", while
>> others want to keep it "1" and "2". 
>>
>> By using place holder, %d, we can translate it %Id and let the locale
>> definition decide which system to be used.
>>
>> On Fri, Apr 25, 2008 at 07:27:17PM +0200, daniel g. siegel wrote:
>> 
>>> using "1", "2", "3" as strings makes more sense to me, as we wont have
>>> any other numbers. i commited it to trunk.
>>>
>>> thanks!
>>>
>>> daniel
>>>
>>> On Wed, 2008-04-23 at 21:31 +0100, Djihed Afifi wrote:
>>>   
>  <>  <في ر، 23-04-2008 عند 22:29 +0200 ، كتب daniel g. siegel:
>   
> hi!
>
> in cheese we got a nice countdown widget, which just counts down from 3
> to 1 and then shows a small camera. those three strings ("1", "2", and
> "3" are not translated). should i make them translatable?
>
> at least i think, there are some people, who do not use arabic numbers.
>
>   
 Hi!

 Please work it out using variable placeholders, i.e %d and a comment.

 That way, we, at the Arabic team (we use both Arabic and Hindu numerals
 for different locales) could just use %Id and the application will
 display the right numerals upon reading the locale. 

 If you use 1, 2, etc verbatim we will just copy them and nobody will get
 the benefit.

 Djihed
 
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: There is already a non-responsive coordinator in kazakh language team

[Simos Xenitellis]

O/H RedLiner έγραψε:
> Yeah, I tried to contact him but I've got only this:
>   
Hi,
Gizat Makhanov showed interest for the Kazakh GNOME Localisation in 
March,  and here is the  reply I gave,
http://mail.gnome.org/archives/gnome-i18n/2008-March/msg00356.html
Please read that e-mail carefully. It also shows the current e-mail of 
the "coordinator".

Kanat Amrenov has not updated his e-mail address at the GNOME Kazakh page,
http://l10n.gnome.org/languages/kk

Kanat replied privately to me at the above at the March e-mail, and I 
notice now that I sent him a private e-mail back (did not CC: the 
mailing list, gnome-i18n).

This is the last e-mail I sent him:

kanat amrenov wrote:
> Hi. I can't login because lost my password. My email not active now. 
> So what can i do ?
These are minor issues. The important part is to complete the Kazakh 
localisation.

a. Send a reply to the first email you received, which was cc:ed to 
gnome-i18n. Use Reply to All.
Mention there that you want to continue to be coordinator.
b. Follow the instructions at
http://live.gnome.org/TranslationProject/JoiningTranslation
to update your details and do any tasks that are pending.
Send an e-mail to update your details (email address, etc) on 
l10n.gnome.org, and bugzilla. They are all well described at the GNOME 
wiki page above.
c. Talk with Gizat, make a mailing list for the Kazakh localisation (use 
Google groups?), transfer any translations from Launchpad to GNOME SVN, 
etc.

Hope this helps,
Simos
==

To the best of my knowledge there was not further email to that.

Although Kanat Amrenov has been somewhat active at Rosetta  with Kazakh 
translations,
https://translations.launchpad.net/~arruah/
he has not done any translations for Kazakh and GNOME.
If he is not able to perform the coordinator tasks, I would suggest 
someone else to take over the Kazakh GNOME team.

Simos

> This is an automatically generated Delivery Status
> Notification
> 
> THIS IS A WARNING MESSAGE ONLY.
> 
> YOU DO NOT NEED TO RESEND YOUR MESSAGE.
> 
> Delivery to the following recipient has been delayed:
> 
>  [EMAIL PROTECTED]
> 
> Message will be retried for 2 more day(s)
> 
> Technical details of temporary failure: 
> TEMP_FAILURE: The recipient server did not accept our
> requests to connect. Learn more at
> http://mail.google.com/support/bin/answer.py?answer=7720
> [sfek.kz (1): Connection timed out]
> 
>- Message header follows -
> 
> Received: by 10.67.10.4 with SMTP id
> n4mr9695189ugi.45.1209659234541;
> Thu, 01 May 2008 09:27:14 -0700 (PDT)
> Return-Path: <[EMAIL PROTECTED]>
> Received: from ?192.168.1.33? ( [89.218.138.163])
> by mx.google.com with ESMTPS id
> z37sm3549341ikz.6.2008.05.01.09.27.11
> (version=TLSv1/SSLv3 cipher=RC4-MD5);
> Thu, 01 May 2008 09:27:13 -0700 (PDT)
> Subject:
> =?UTF-8?Q?=D0=9F=D0=B5=D1=80=D0=B5=D0=B2=D0=BE=D0=B4?=
> GNOME
> =?UTF-8?Q?=D0=BD=D0=B0?=
> 
> =?UTF-8?Q?_=D0=BA=D0=B0=D0=B7=D0=B0=D1=85=D1=81=D0=BA=D0=B8=D0=B9?=
> From: RedLiner <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Content-Type: text/plain; charset=UTF-8
> Date: Thu, 01 May 2008 22:27:43 +0600
> Message-Id: <[EMAIL PROTECTED]>
> Mime-Version: 1.0
> X-Mailer: Evolution 2.22.1 
> Content-Transfer-Encoding: 8bit
> 
>- Message body suppressed -
>
>
> В Сбт, 03/05/2008 в 10:20 +0200, Johannes Schmid пишет:
>   
>> Hi!
>>
>> Could you give some more details? Have you tried to contact him? When?
>> Did you get any reply? Is anyone willing to take over coordination?
>>
>> Thanks,
>> Johannes
>>
>>
>> Am Samstag, den 03.05.2008, 11:36 +0600 schrieb RedLiner:
>> 

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: There is already a non-responsive coordinator in kazakh language team

[Simos Xenitellis]

O/H RedLiner έγραψε:
> В Сбт, 03/05/2008 в 09:57 +0100, Simos Xenitellis пишет:
> And Who will be a new coordinator?
>   
I think this is something that the three of you can discuss 
("Redliner.KZ", Kanat, Gizat) between each other.

Do you think you can do that and come back to this list with a plan?

Simos

>> O/H RedLiner έγραψε:
>> 
>>> Yeah, I tried to contact him but I've got only this:
>>>   
>>>   
>> Hi,
>> Gizat Makhanov showed interest for the Kazakh GNOME Localisation in 
>> March,  and here is the  reply I gave,
>> http://mail.gnome.org/archives/gnome-i18n/2008-March/msg00356.html
>> Please read that e-mail carefully. It also shows the current e-mail of 
>> the "coordinator".
>>
>> Kanat Amrenov has not updated his e-mail address at the GNOME Kazakh page,
>> http://l10n.gnome.org/languages/kk
>>
>> Kanat replied privately to me at the above at the March e-mail, and I 
>> notice now that I sent him a private e-mail back (did not CC: the 
>> mailing list, gnome-i18n).
>>
>> This is the last e-mail I sent him:
>> 
>> kanat amrenov wrote:
>> 
>>> Hi. I can't login because lost my password. My email not active now. 
>>> So what can i do ?
>>>   
>> These are minor issues. The important part is to complete the Kazakh 
>> localisation.
>>
>> a. Send a reply to the first email you received, which was cc:ed to 
>> gnome-i18n. Use Reply to All.
>> Mention there that you want to continue to be coordinator.
>> b. Follow the instructions at
>> http://live.gnome.org/TranslationProject/JoiningTranslation
>> to update your details and do any tasks that are pending.
>> Send an e-mail to update your details (email address, etc) on 
>> l10n.gnome.org, and bugzilla. They are all well described at the GNOME 
>> wiki page above.
>> c. Talk with Gizat, make a mailing list for the Kazakh localisation (use 
>> Google groups?), transfer any translations from Launchpad to GNOME SVN, 
>> etc.
>>
>> Hope this helps,
>> Simos
>> ==
>>
>> To the best of my knowledge there was not further email to that.
>>
>> Although Kanat Amrenov has been somewhat active at Rosetta  with Kazakh 
>> translations,
>> https://translations.launchpad.net/~arruah/
>> he has not done any translations for Kazakh and GNOME.
>> If he is not able to perform the coordinator tasks, I would suggest 
>> someone else to take over the Kazakh GNOME team.
>>
>> Simos
>>
>> 
>>> This is an automatically generated Delivery Status
>>> Notification
>>> 
>>> THIS IS A WARNING MESSAGE ONLY.
>>> 
>>> YOU DO NOT NEED TO RESEND YOUR MESSAGE.
>>> 
>>> Delivery to the following recipient has been delayed:
>>> 
>>>  [EMAIL PROTECTED]
>>> 
>>> Message will be retried for 2 more day(s)
>>> 
>>> Technical details of temporary failure: 
>>> TEMP_FAILURE: The recipient server did not accept our
>>> requests to connect. Learn more at
>>> http://mail.google.com/support/bin/answer.py?answer=7720
>>> [sfek.kz (1): Connection timed out]
>>> 
>>>- Message header follows -
>>> 
>>> Received: by 10.67.10.4 with SMTP id
>>> n4mr9695189ugi.45.1209659234541;
>>> Thu, 01 May 2008 09:27:14 -0700 (PDT)
>>> Return-Path: <[EMAIL PROTECTED]>
>>> Received: from ?192.168.1.33? ( [89.218.138.163])
>>> by mx.google.com with ESMTPS id
>>> z37sm3549341ikz.6.2008.05.01.09.27.11
>>> (version=TLSv1/SSLv3 cipher=RC4-MD5);
>>> Thu, 01 May 2008 09:27:13 -0700 (PDT)
>>> Subject:
>>> =?UTF-8?Q?=D0=9F=D0=B5=D1=80=D0=B5=D0=B2=D0=BE=D0=B4?=
>>> GNOME
>>> =?UTF-8?Q?=D0=BD=D0=B0?=
>>> 
>>> =?UTF-8?Q?_=D0=BA=D0=B0=D0=B7=D0=B0=D1=85=D1=81=D0=BA=D0=B8=D0=B9?=
>>> From: RedLiner <[EMAIL PROTECTED]>
>>

Re: problem with translating totem

[Simos Xenitellis]

O/H Mohammad Foroughi έγραψε:
>> please fix this fatal error first, and try again.
>> (or post both the msgstr/msgid from that line number here if the error
>> is not clear.)
>> 
>
> Ok, I fixed it:
>
> [EMAIL PROTECTED]:~$ msgfmt -cv ./Desktop/po/totem.HEAD.fa.po 405 translated
> messages, 19 fuzzy translations, 73 untranslated messages.
>
> [EMAIL PROTECTED]:~$ sudo msgfmt ./Desktop/po/totem.HEAD.fa.po
> -o /usr/share/locale-langpack/fa/LC_MESSAGES/totem.mo 
>
> But the problem still exist :(
>   
One thing that you do not mention is what distribution you are using to 
test your translations.
 From the previous e-mails, you grabbed the PO files for what we call 
HEAD (or trunk), which can be slightly different from, let's say, the 
totem version you get in Ubuntu 8.04.
For example, in totem in Ubuntu 8.04, the original message could be 
something like "Skip _me: " but in the latest development version of 
Totem, it could have changed to "Skip _me:" (notice the space 
different). Thus, while a fully translated HEAD PO file is excellent for 
the new version of Ubuntu, for the current version some messages may not 
show up.

If you really want to have all messages appear as you have with your 
.HEAD.po files, you may want to compile the latest version of GNOME, 
using JhBuild.
However, this task is somewhat technical and requires resources in terms 
of disk space and bandwidth.

The typical workflow for (some?) translators is to translate as much as 
possible, and near the string freeze, you install a test/beta version of 
a distribution (such as Ubuntu). Because the messages between what is in 
the PO file and the Linux distribution will be ~100% identical, you can 
do easy and comfortable testing/quality control.

To sum up, continue translating and doing rough testing at the moment, 
and do the proper quality control near the string freeze time (around 
August/September?), using something like an Alpha version of Ubuntu of 
that time.

I hope this helps,
Simos

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: problem with translating totem

[Simos Xenitellis]

O/H Mohammad Foroughi έγραψε:
>> One thing that you do not mention is what distribution you are using to 
>> test your translations.
>>  From the previous e-mails, you grabbed the PO files for what we call 
>> HEAD (or trunk), which can be slightly different from, let's say, the 
>> totem version you get in Ubuntu 8.04.
>> For example, in totem in Ubuntu 8.04, the original message could be 
>> something like "Skip _me: " but in the latest development version of 
>> Totem, it could have changed to "Skip _me:" (notice the space 
>> different). Thus, while a fully translated HEAD PO file is excellent for 
>> the new version of Ubuntu, for the current version some messages may not 
>> show up.
>> 
>
> Ok,
>
>  I wanna translate ubuntu 8.04
>
>  Currently I am using HEAD, is this wrong? if yes, what version I must
> use?
>   
First of all, you did not quote correctly the email you are replying to. 
The part "Person XYZ wrote:" is missing from the section you quote. It 
is important to include that section.

Secondly, in the same original e-mail that you quote from, it describes 
a common work flow (you forgot to quote that paragraph), and actually 
gives the answer to the question you are asking here.

It is very important to get these details correct, otherwise you may 
give the impression to be disrespectful.

Simos

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: New Polish team coordinator

[Simos Xenitellis]

Wadim,

1. Please send again this e-mail, but this time include Artur in the CC: 
of the email.
2. Artur should reply to that new e-mail, thanking you for taking the 
reigns of the Polish GNOME Team.
3. The change-over is complete!

Simos


O/H wadim dziedzic έγραψε:
> hello everybody,
>
> I would like to announce that Artur Flinta has resigned from the role of
> coordination for Polish. We have agreed, that I will be his sucessor.
>
> Once more big thanks to Artur for his work!
>
> regards,
> Wadim
>
> p.s. could someone write here or point me to a description on how to
> switch the bugzilla assignee and team description on l10n.gnome.org?
>
>   

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: A coordinator with very long response time

[Simos Xenitellis]

O/H Arash Mousavi έγραψε:
> On Thu, May 15, 2008 at 10:23 PM, Behdad Esfahbod <[EMAIL PROTECTED]> wrote:
>   
>> On Thu, 2008-05-15 at 22:17 +0430, Mostafa Daneshvar wrote:
>> 
>>> On Panj shanbe 26 Ordibehesht 1387 21:46:37 Behdad Esfahbod wrote:
>>>   
 On Thu, 2008-05-15 at 10:15 -0700, Roozbeh Pournader wrote:
 
> On Thu, May 15, 2008 at 8:12 AM, Behdad Esfahbod <[EMAIL PROTECTED]>
>   
>>> wrote:
>>>   
>> It's a pity that people tend to
>> take behaviors like this mail of yours as a sign that you are unwilling
>> to work as part of a team, and that limits your opportunities.
>> 
> I don't understand this. Does the "people" you are referring to here
> mean me? Or this is just some comment against the whole humanity?
>   
 It's just a polite way to say "stop your self-destructing behavior".

 
> Roozbeh
>   
>>> Once again Iranian battels.
>>>   
>> I don't know what you are trying to gain here.  This whole recent
>> threads fed by you and Mohammad Foroughi has been quite disrespectful
>> to the entire Persian team who has been contributing to GNOME for, what,
>> eight years now.
>>
>> I don't get it.  I don't see what this is about.  GNOME is a
>> meritocracy.  Show me your merits.  Just because you speak Persian
>> doesn't mean you are a good translator.  Or you know about GNOME
>> processes.  I'm willing to help you integrate in the team.  But can't
>> help if you are not cooperative.  If you continue your rude behavior.
>>
>> This is my last message in this thread.  If you need to talk to me, you
>> have my personal address.
>>
>> --
>> behdad
>> http://behdad.org/
>>
>> "Those who would give up Essential Liberty to purchase a little
>>  Temporary Safety, deserve neither Liberty nor Safety."
>>-- Benjamin Franklin, 1759
>> 
>
> Dear my friends;
>
> I think all that has happened so far, in here and in Technotux forums,
> are just caused by some misunderstandings. We are a team and we have a
> same goal. And I think the new group of translators has shown their
> faithfulness with sending translations. Lets just keep working on our
> goal.
>   
If you read this thread carefully, you will notice that there was a 
subtle misunderstanding.
Roozbeh thought that he was criticized by Behdad, however Behdad was not 
referring to him.

This guy, Mohammad, is such a negative force that I would hate to have 
on my team. I would refuse to accept translations, or worse, direct him 
to KDE I18n.

Simos

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

damned lies, anjuta documentation and encoding bug

[Simos Xenitellis]

Hi All,
When viewing the status pages such as
http://l10n.gnome.org/languages/zh_HK/gnome-2-24
one can see the error:

Download po file 
 anjuta 
 [Error regenerating POT file for 
document help.HEAD: cd ] doSerialize(doc) File "/usr/bin/xml2po", 
line 602, in doSerialize outtxt += doSerialize(child) File 
"/usr/bin/xml2po", line 596, in doSerialize (starttag, content, endtag, 
translation) = processElementTag(node, repl, 1) File "/usr/bin/xml2po", 
line 496, in processElementTag myrepl.append(processElementTag(child, 
myrepl, 1)) File "/usr/bin/xml2po", line 496, in processElementTag 
myrepl.append(processElementTag(child, myrepl, 1)) File 
"/usr/bin/xml2po", line 496, in processElementTag 
myrepl.append(processElementTag(child, myrepl, 1)) File 
"/usr/bin/xml2po", line 496, in processElementTag 
myrepl.append(processElementTag(child, myrepl, 1)) File 
"/usr/bin/xml2po", line 534, in processElementTag translation = 
translation.replace(u'' % (i), replacement) UnicodeDecodeError: 'ascii' 
codec can't decode byte 0xe2 in position 95: ordinal not in range(128)" />

Source file:
http://l10n.gnome.org/POT/anjuta.HEAD/docs/help.HEAD.pot

It appears that the mere fact the POT file has a non-ascii character 
causes damned-lies to break.
The offending character apparently is … (ellipsis character), due to the 
0xe2 hint.
It is strange because other POT/PO files have non-ASCII characters as 
well, such as evince and epiphany.

If someone can figure out what's wrong, it would be great.

Talking about encodings in POT files, here is a recent discussion going on,
http://blogs.gnome.org/simos/2008/05/14/should-ui-strings-in-source-code-have-non-ascii-characters/

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: One key stroke --> two code-points

[Simos Xenitellis]

O/H Javier SOLA έγραψε:

Hi,

I am working on Khmer localization (KhmerOS project).

In Khmer, some of the basic vowels (which we include in the keyboard) 
require two code-points, so one keystroke must generate two code points.


It used to be that we could do the conversion in KBX by generating a 
fictious code-point (Pablo Saratxaga explained this to us a few years 
ago), which was later translated to two real code-points by puting the 
conversion in the en-US locale file. I did work at the time.


But now this seems to have stopped working. Does anybody knows how we 
can fix this? 
These additions (pressing a single key and producing two codepoints), 
are located at

/usr/share/X11/locale/en_US.UTF-8/Compose
The specific lines appear to be

# Khmer digraphs
# A keystroke has to generate several characters, so they are defined
# in this file

:   "ុះ"
:   "ុំ"
:   "េះ"
:   "ោះ"
:   "ាំ"

GTK+ based applications duplicate the Compose file in the gtk+ library, 
and currently the version of the Compose file that exists in gtk+ does 
not include those specific compose sequences.

I think these are a recent addition.
Technically, it is possible for gtk+ to include compose sequences that 
produce more than one code points (requires small change in the code), 
however these recent Khmer digraphs are the only compose sequences using 
the facility now.


To cut the long story short, you can bypass for now the GTK+ version of 
the Compose file and use the Compose file that comes with X.Org (shown 
above) by setting the environment variable GTK_IM_MODULE to "xim".

This should not have adverse effect to the OLPC software.

It is important that if other keyboard layouts as well require compose 
sequences that produce
two or more codepoints (such as Serbian), to add them to the XOrg 
Compose file. In the next iteration of update of the GTK+, all these 
compose sequences can make it in.


Simos


___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: One key stroke --> two code-points

[Simos Xenitellis]

O/H Javier SOLA έγραψε:

Thanks Simos !!

Actually, we have had these additions for a while in X11.

Hi Javier,

Checking at
http://gitweb.freedesktop.org/?p=xorg/lib/libX11.git;a=tree;f=nls/en_US.UTF-8
does not show these lines at the end. It is possible that these compose 
sequences were added as a patch to the distribution package.


We will  do an issue for GTK+, and use the variable meanwhile.

What file is it in GTK+? I have not been able to find it.

In GTK+ (HEAD), the relevant file is
http://svn.gnome.org/viewvc/gtk%2B/trunk/gtk/gtkimcontextsimple.c?view=markup

However, your case of compose sequences is different from the existing 
compose sequences, that result to a single codepoint (you require to 
produce two codepoints).


Therefore, the type of support you are looking for is similar to compose 
sequences that result to letter+diacritic mark. Several languages have 
characters that no pre-composed  letters exist, so the compose sequence  
produces letter+diacritic marks (more than one codepoint). Such support 
is missing, and there are already bug reports for them.


Bug 341341 – Compose mechanism in simple input method doesn't support 
decomposed forms

http://bugzilla.gnome.org/show_bug.cgi?id=341341

Bug 345254 – dead accents should at least produce combining characters
http://bugzilla.gnome.org/show_bug.cgi?id=345254

There is a shortcut when trying to solve the above cases of compose 
sequences, thus the solution I expect to be different from the Khmer 
compose sequences.
Specifically, for the Latin compose sequences, such as (it's a made up 
example)


  : "t́" # LETTER T WITH ACUTE

one could convert to something like[ dead_acute, 't', 0].
We would put 0 for the resulting codepoint because we can deduce for 
this category of compose sequences that the actual codepoints are 't' 
and 'acute' (the resulting codepoints match the body of the compose 
sequence).


However, for the case of Khmer, the compose sequences look independent 
from the resulting code points. Therefore, a new table should be required.


To cut the story short, I have filed a bug report for this,
Bug 537457 – Support compose sequences that produce two+ codepoints
http://bugzilla.gnome.org/show_bug.cgi?id=537457

Simos



Thanks,

Javier

Simos Xenitellis wrote

O/H Javier SOLA έγραψε:

Hi,

I am working on Khmer localization (KhmerOS project).

In Khmer, some of the basic vowels (which we include in the 
keyboard) require two code-points, so one keystroke must generate 
two code points.


It used to be that we could do the conversion in KBX by generating a 
fictious code-point (Pablo Saratxaga explained this to us a few 
years ago), which was later translated to two real code-points by 
puting the conversion in the en-US locale file. I did work at the time.


But now this seems to have stopped working. Does anybody knows how 
we can fix this? 
These additions (pressing a single key and producing two codepoints), 
are located at

/usr/share/X11/locale/en_US.UTF-8/Compose
The specific lines appear to be

# Khmer digraphs
# A keystroke has to generate several characters, so they are defined
# in this file

:   "ុះ"
:   "ុំ"
:   "េះ"
:   "ោះ"
:   "ាំ"

GTK+ based applications duplicate the Compose file in the gtk+ 
library, and currently the version of the Compose file that exists in 
gtk+ does not include those specific compose sequences.

I think these are a recent addition.
Technically, it is possible for gtk+ to include compose sequences 
that produce more than one code points (requires small change in the 
code), however these recent Khmer digraphs are the only compose 
sequences using the facility now.


To cut the long story short, you can bypass for now the GTK+ version 
of the Compose file and use the Compose file that comes with X.Org 
(shown above) by setting the environment variable GTK_IM_MODULE to 
"xim".

This should not have adverse effect to the OLPC software.

It is important that if other keyboard layouts as well require 
compose sequences that produce
two or more codepoints (such as Serbian), to add them to the XOrg 
Compose file. In the next iteration of update of the GTK+, all these 
compose sequences can make it in.


Simos







___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: One key stroke --> two code-points

[Simos Xenitellis]

O/H Clytie Siddall έγραψε:
Just checking: so this problem does not affect languages using 
precomposed Unicode?


Vietnamese users _should_ be using precomposed forms for our added and 
combined diacritics. But I wonder if we should be ready for the fact 
that they might not. I was using a keyboard layout for a while which 
was decomposed, and I didn't know it. That could happen to others, too.

With precomposed characters, the compose sequences look like

--->  single codepoint

Producing a single codepoint is well defined, and has been available 
from the start.


When no precomposed forms exist, then

--->  codepointA, codepointB

This was not used in the X.Org Compose file (the Khmer compose 
sequences, first such sequences,

were added to X.Org just a few days back).

One thing I do not know about the Vietnamese written language is,
are there characters (with combined diacritics) that no corresponding 
precomposed forms exist?
That is, do characters exist that you cannot type them using the typical 
dead keys?


However, if there is a need for decomposed forms anyway, it is good know 
about it.


For Vietnamese, it is important to look at the xkeyboard-config project 
and check

what does default layout do, and that it is a reasonable choice.

Simos


Clytie

On 10/06/2008, at 2:35 PM, Anousak Souphavanh wrote:


Thanks, Simos for your kind and time.

Much appreciated to Javier for brought a good solution indeed.

Lao input method  is need a similar solution. Javier please post your
solution (where and how to define a new table for Khmer) so I can
define these code points for Lao.


On Tue, Jun 10, 2008 at 1:58 AM, Simos Xenitellis
<[EMAIL PROTECTED]> wrote:

O/H Javier SOLA έγραψε:


Thanks Simos !!

Actually, we have had these additions for a while in X11.


Hi Javier,

Checking at
http://gitweb.freedesktop.org/?p=xorg/lib/libX11.git;a=tree;f=nls/en_US.UTF-8 

does not show these lines at the end. It is possible that these 
compose

sequences were added as a patch to the distribution package.


We will  do an issue for GTK+, and use the variable meanwhile.

What file is it in GTK+? I have not been able to find it.


In GTK+ (HEAD), the relevant file is
http://svn.gnome.org/viewvc/gtk%2B/trunk/gtk/gtkimcontextsimple.c?view=markup 



However, your case of compose sequences is different from the existing
compose sequences, that result to a single codepoint (you require 
to produce

two codepoints).

Therefore, the type of support you are looking for is similar to 
compose

sequences that result to letter+diacritic mark. Several languages have
characters that no pre-composed  letters exist, so the compose 
sequence
produces letter+diacritic marks (more than one codepoint). Such 
support is

missing, and there are already bug reports for them.

Bug 341341 – Compose mechanism in simple input method doesn't support
decomposed forms
http://bugzilla.gnome.org/show_bug.cgi?id=341341

Bug 345254 – dead accents should at least produce combining characters
http://bugzilla.gnome.org/show_bug.cgi?id=345254

There is a shortcut when trying to solve the above cases of compose
sequences, thus the solution I expect to be different from the 
Khmer compose

sequences.
Specifically, for the Latin compose sequences, such as (it's a made up
example)

  : "t́" # LETTER T WITH ACUTE

one could convert to something like[ dead_acute, 't', 0].
We would put 0 for the resulting codepoint because we can deduce 
for this
category of compose sequences that the actual codepoints are 't' 
and 'acute'

(the resulting codepoints match the body of the compose sequence).

However, for the case of Khmer, the compose sequences look 
independent from

the resulting code points. Therefore, a new table should be required.

To cut the story short, I have filed a bug report for this,
Bug 537457 – Support compose sequences that produce two+ codepoints
http://bugzilla.gnome.org/show_bug.cgi?id=537457

Simos



Thanks,

Javier

Simos Xenitellis wrote


O/H Javier SOLA έγραψε:


Hi,

I am working on Khmer localization (KhmerOS project).

In Khmer, some of the basic vowels (which we include in the 
keyboard)
require two code-points, so one keystroke must generate two code 
points.


It used to be that we could do the conversion in KBX by 
generating a
fictious code-point (Pablo Saratxaga explained this to us a few 
years ago),
which was later translated to two real code-points by puting the 
conversion

in the en-US locale file. I did work at the time.

But now this seems to have stopped working. Does anybody knows 
how we

can fix this?


These additions (pressing a single key and producing two 
codepoints), are

located at
/usr/share/X11/locale/en_US.UTF-8/Compose
The specific lines appear to be

# Khmer digraphs
# A keystroke has to generate several characters, so they are 
defined

# in this file

:   "ុះ"
:   "ុំ"
:   "

Re: Teams cleanup

[Simos Xenitellis]

O/H Gil Forcada έγραψε:

Hi,

Maybe adding another property in translations-teams.xml.in like:

  
<_language id="en_CA">Canadian English

http://www.vectors.cx/en_ca.html
  

And in http://l10n.gnome.org/teams sort first the ones without the
"stalled" (or whatever you like to call those) property and then the
others?

I don't like having them mixed, because can give the bad sense that
there are more active projects that the real ones.
  

Having this information in the XML file is a great idea.

I believe it would be good to use the "stalled" information when
someone is viewing the language page, as in
http://l10n.gnome.org/languages/LL/
and any other pages under that URL.

What we could put (with fancy HTML, on one of the top corners of the 
page) is something like


"This translation team has been inactive for a long time.
If you wish to take over the team,
please register at the gnome-i18n mailing list
and request to start working for this language."

Simos


My 5 cents.

Cheers,


El dj 19 de 06 de 2008 a les 16:16 +0530, en/na Sankarshan (সঙ্কর্ষণ) va
escriure:
  

On Thu, Jun 19, 2008 at 2:44 AM, Christian Rose <[EMAIL PROTECTED]> wrote:


On 6/16/08, Claude Paroz <[EMAIL PROTECTED]> wrote:
  

 I plan to hide all teams/languages with 0 translated strings in
 l10n.gnome.org, except maybe those who requested a new team in the last
 six months.
 IMHO, it gives the wrong illusion that an effort is being done in that
 language.

 Are there opponents?


I'm not sure *hiding* the information is the best option; perhaps just
promptly marking the team as "defunct" or "coordinator volunteers
wanted" or something like that will do?
  

Marking languages as ones which can do with volunteer love would be a
good way to go.

~sankarshan



  


___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: damned lies, anjuta documentation and encoding bug

[Simos Xenitellis]

O/H Tomas Kuliavas έγραψε:

Hi!



C/anjuta-manual.xml strings have 8bit symbols
  

OK, can someone give me a simple command to convert from the original
encoding to utf-8? Or can I just use gedit to convert it?



C/anjuta-manual.xml is already in utf-8.

Problem is not in anjuta-manual.xml, but in xml2po script which assumes
that file is in ascii. "UnicodeDecodeError: 'ascii' codec can't decode
byte 0xe2 in position 95". That's what strict charset conversion tools do,
when you try to convert something and input does not match specified input
charset.
  

I try to replicate on my system but I do not get an error:

xml2po -o /tmp/test.po C/anjuta-manual.xml

I set my current locale to C, Posix, etc. and also make sure the 
encoding for Python in ascii.
I notice that the xml2po on the l10n.gnome.org server is different from 
my xml2po (the line numbers do not match when looking into the error 
shown in the stats pages).

Has anyone managed to reproduce on their systems?

Also, another thing is that the header of the document does not specify 
encoding,




Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Translated files need to be uploaded: Pashto team

[Simos Xenitellis]

2008/7/1 Zabeeh khan <[EMAIL PROTECTED]>:
>> Brother Khalid, the coordinator of Pashto team, agrees that my translated
>> files should be uploaded to the repository. Please someone upload them:
>>
>> http://bugzilla.gnome.org/show_bug.cgi?id=533060

I just uploaded the translations.

Thanks for your translation work.

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Slowness in farsi translation

[Simos Xenitellis]

O/H Tomas Kuliavas έγραψε:

If Sharif Linux is 100%
translated, it can't be explained by limited number of packages and
Linux
distribution differences unless Persian Gnome 2.10 translation was close
to 100% and it degraded to 74% in 2.14 due to lots of changes in
translations. I don't think that translation can lose 25% of strings in
just two major Gnome releases.
  

I don't understand this line of reasoning at all. Please explain.
Where did you get your numbers from? What do you think happened?



http://l10n.gnome.org/languages/fa UI stats

Gnome 2.14 - 74%
Gnome 2.16 - 74%
Gnome 2.18 - 68%
Gnome 2.20 - 63%
Gnome 2.22 - 55%
Gnome 2.24-dev - 51%

Sarif Linux is some customized redhat/fedora based distribution. It uses
Gnome 2.10. I don't have information about standard Gnome 2.10 UI Farsi
translation stats. Screenshots look fully translated.
  
Tomas, it is important to include the lines such as "On , PersonA 
wrote:".
Reading above, I have to search through the e-mail to figure out who are 
the two people you quote.


In order to get a distribution fully translated, you do not need to have 
a 100% translation at the GNOME stats. GNOME includes packages that may 
or may not be included in a distribution. I think it has already been 
explained. Therefore, there should be no conspiracy with a 25% fall 
between 2.10 to 2.14.


I think Christian captured the debate in his e-mail very well, and it 
looks that this is where we stand.


Reading the most recent e-mail by Mohammad, I see that he is still 
maintaining an aggressive stance.
I would suggest that if he apologises, post the translations to Bugzilla 
(like Zabeeh did), things might move on.
I am skeptical that such a change of behaviour can occur, however I wish 
I am proven wrong.


Andre, in an earlier e-mail reminded us of the GNOME Code of Conduct,
http://live.gnome.org/CodeOfConduct

I copy a part of it:

   * Be respectful and considerate:
 o Disagreement is no excuse for poor behaviour or personal
   attacks. Remember that a community where people feel
   uncomfortable is not a productive one.


 Applies to

   *

 GNOME Bugzilla 

   *

 GNOME mailing lists 

 o Individuals who signed at
   http://live.gnome.org/CodeOfConduct/Signatures

A step to the right direction would be to sign up on 
http://live.gnome.org/CodeOfConduct/Signatures and show explicitly that 
we abide by the GNOME Code of Conduct.


Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Slowness in farsi translation

[Simos Xenitellis]

O/H Abbas Esmaeeli Some'eh έγραψε:

On Wed, 2 Jul 2008 16:26:52 +0430
"s.m ziaei" <[EMAIL PROTECTED]> wrote:

  

Imam Ali (AS) :
Like your friend enough mayhap he will convert to your enemy
And hate your enemy enough mayhap he will convert to your friend.
امام علی(ع( :
دوستت را به اندازه دوست بدار چه بسا روزی دشمنت گردد
و دشمنت را باندازه دشمن دار شاید روزی به دوست تو بدل گردد.




بابا جمع کن این بساط نصیحت کردنت رو. اینجا لیست پستی گنوم هست، نه حوزه
علمیه قم. یه هفته هست هی داری اسپم می‌فرستی به لیست.
  

Dear S.M. and Abbas,

This is an English-speaking mailing list.
Ignoring the good intentions, it is rude to write in another language.

Simos

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Importing Pashto translation files from Launchpad

[Simos Xenitellis]

2008/7/4 Zabeeh khan <[EMAIL PROTECTED]>:
> Hello,
>
> Brother Khalid, if you have translated anything there in Launchpad, please
> import it to the GNOME repository. As we know Pashto translation is going
> too slow, so it might help increase the percentages. I have translated some
> other files too, soon will I try to commit them.
>
>
> A few days back some of my translations were commited by Simos, but there is
> no increase in percentages and I cannot see the names of the packages there
> too?

Hi Zabeeh,
I uploaded your two translations, netspeed and gnome-system-monitor.

netspeed can be found at GNOME Extras
http://l10n.gnome.org/languages/ps/gnome-extras

gnome-system-monitor can be found at GNOME 2.24 Development,
http://l10n.gnome.org/languages/ps/gnome-2-24

If I were to suggest the next translations, I would put
1. gnome-menus (from GNOME 2.24 Development)
This are the menus, which are the first to see.

2. gtk+ UI translations (from GNOME 2.24 Development)
It is a big file, and some of the messages can be found in many programs.
You can select which messages to translate.
For example,

#: ../gtk/gtkstock.c:368
msgid "_Network"
msgstr ""

#: ../gtk/gtkstock.c:369
msgid "_New"
msgstr ""

#: ../gtk/gtkstock.c:370
msgid "_No"
msgstr ""

#: ../gtk/gtkstock.c:371
msgid "_OK"
msgstr ""

#: ../gtk/gtkstock.c:372
msgid "_Open"
msgstr ""

Most of the programs reuse those messages, so you translate once here
and automatically all other programs will use.

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Importing Pashto translation files from Launchpad

[Simos Xenitellis]

On Fri, Jul 4, 2008 at 2:23 PM, Andre Klapper <[EMAIL PROTECTED]> wrote:
> Am Freitag, den 04.07.2008, 13:45 +0100 schrieb Simos Xenitellis:
>> If I were to suggest the next translations, I would put
>> 1. gnome-menus (from GNOME 2.24 Development)
>> 2. gtk+ UI translations (from GNOME 2.24 Development)
>
> Simos, want to add gnome-menus to "Choosing the first packages to
> translate" at
> http://live.gnome.org/TranslationProject/LocalisationGuide#head-006b8d2286e54d97ff6106b012d9f1196e60
> ?

Andre,
I just added the text, here is the diff,

http://live.gnome.org/action/info/TranslationProject/LocalisationGuide?action=diff&rev2=10&rev1=9

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Gimp traslations

[Simos Xenitellis]

On Tue, Jul 8, 2008 at 4:39 AM, Khoem Sokhem <[EMAIL PROTECTED]> wrote:
> Hello All,
>
> I just got openSUSE 11.0 box yesterday and Installed in my pc, Gimp one of my
> translated applications in openSUSE. but unfortunately when I test beta
> release of openSUSE 11.0 I got Gimp in Khmer but after I installed openSUSE
> 11.0 GM realease I got Gimp in English.
> What is the problem with this?

This looks like a distribution issue. Does openSUSE support "language packs";
If so, do you have the Khmer language pack installed?

If you are OK to use the command line, you can use the following
commands to see whether GIMP tries to open the Khmer translations:

1. Open a terminal window
2. Type "locale" to verify that your locale is kh.
3. Run   strace -o /tmp/detailed_run.txt  gimp
You may need to install the "strace" package.
4. Then, read the /tmp/detailed_run.txt file and see if the program is
trying to find Khmer translations.
You can also do that with the command

grep locale /tmp/detailed_run.txt

For me (locale: el), I get lines that look like

...
open("/usr/share/locale-langpack/el.UTF-8/LC_MESSAGES/gimp20-script-fu.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/el.utf8/LC_MESSAGES/gimp20-script-fu.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale-langpack/el/LC_MESSAGES/gimp20-script-fu.mo",
O_RDONLY) = 8
...

This shows that the translation message file gimp20-script-fu.mo is
actually found after several attempts.

If you would like some more technical help on the above process,
please ask again.

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: What's with anjuta and damned lies?

[Simos Xenitellis]

On Tue, Jul 15, 2008 at 9:11 PM, Claude Paroz <[EMAIL PROTECTED]> wrote:
> Le lundi 05 mai 2008 à 16:38 +0200, Tino Meinen a écrit :
>> Looking at http://l10n.gnome.org/module/anjuta there seems to be
>> something fishy going on at the moment.
>> It's displaying:
>>
>> cd
>> "/var/www/damned-lies/scratchdir/svn/anjuta.HEAD/manuals/anjuta-manual"
>> && xml2po
>> -o 
>> /var/www/damned-lies/scratchdir/svn/anjuta.HEAD/manuals/anjuta-manual/C/help.HEAD.pot
>>  -e  C/anjuta-manual.xml
>> Traceback (most recent call last):
>>   File "/usr/bin/xml2po", line 869, in
>> doSerialize(doc)
>>   File "/usr/bin/xml2po", line 602, in doSerialize
>> outtxt += doSerialize(child)
>>   File "/usr/bin/xml2po", line 596, in doSerialize
>> (starttag, content, endtag, translation) = processElementTag(node, repl, 
>> 1)
>> etc...
>
> Yeah, Danilo fixed the xml2po bug and the page is now displaying without
> error.

Great news!

Out of curiosity, what was the source of the problem?

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: major libgweather Locations updates

[Simos Xenitellis]

On Mon, Aug 4, 2008 at 2:24 AM, Dan Winship <[EMAIL PROTECTED]> wrote:
> I've just committed a huge update to libgweather's Locations.xml.in.
> From an i18n perspective, the big changes are that a lot of strings
> representing airport names, etc, went away and were replaced with actual
> city names. Also, many city names in some countries were replaced with
> better-localized/better-transliterated versions.
>
> This is unfortunately a huge amount of churn in an already-huge list of
> translatable strings. Two suggestions:
>
>1) Search the po file comments for "This is the capital of", which
>   will let you find national capitals, which are presumably more
>   likely than average to need special translations. Also, search
>   for "is the traditional English name" to find cities that are
>   called something different in English than they are in the
>   local language, which usually also points to the need for a
>   translation.
>
>2) Other than that, wait a week or so (or more) before translating
>   anything, and don't clean out the now-unused translations right
>   away, because we'll be requesting some help from gnome-love
>   which may result in some lame cities being removed and other ones
>   being renamed, etc. Also, once GNOME 2.23.6 is out there, we're
>   going to bump the intltool requirement to the latest version,
>   which will let us add msgctxts to disambiguate duplicate names
>   (eg the US state of Georgia vs the former Soviet Republic of
>   Georgia).

For Greece I have noticed the following,

a. The names in the original strings now have accents, such as
Alexandroúpolis, which helps non-native speakers. This is cool, but
also means that more messages require attention for subtle changes.
I think it's a move to the right direction.

b. There are multiple entries for airports, having them associated
with several nearby cities. For example, for LGKV, there are entries
for four cities, Chrysoúpolis, Dráma, Kavála, Xánthi.
http://maps.google.com/maps?f=q&hl=en&geocode=&q=%CE%BA%CE%B1%CE%B2%CE%AC%CE%BB%CE%B1,+%CE%B5%CE%BB%CE%BB%CE%AC%CE%B4%CE%B1&sll=34.741612,-95.625&sspn=68.827616,113.203125&ie=UTF8&ll=41.109365,24.535217&spn=0.512179,0.884399&t=p&z=10

How much is the radius you picked when considering nearby cities? Is
it more than 50Km?

c. In some cases, the transliterated version does not have an accent.
For example,

Chrysoúpolis Airport and
Chrysoupoli Airport

It looks as if the airport name of the original entry gets the
transliteration, while the nearby cities do not get transliteration of
the airport name.

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: major libgweather Locations updates

[Simos Xenitellis]

On Mon, Aug 4, 2008 at 12:52 PM, Dan Winship <[EMAIL PROTECTED]> wrote:
> Simos Xenitellis wrote:
>> For Greece I have noticed the following,
>>
>> a. The names in the original strings now have accents, such as
>> Alexandroúpolis, which helps non-native speakers. This is cool, but
>> also means that more messages require attention for subtle changes.
>> I think it's a move to the right direction.
>
> We could optionally strip the diacritics out for 2.24 to reduce the
> number of new strings, and then bring them back post-2.24?

My preference would be to keep the transliterated version with diacritics.
Sorry for not being clear.

Thanks for the work,
Simos

>> b. There are multiple entries for airports, having them associated
>> with several nearby cities. For example, for LGKV, there are entries
>> for four cities, Chrysoúpolis, Dráma, Kavála, Xánthi.
>> http://maps.google.com/maps?f=q&hl=en&geocode=&q=%CE%BA%CE%B1%CE%B2%CE%AC%CE%BB%CE%B1,+%CE%B5%CE%BB%CE%BB%CE%AC%CE%B4%CE%B1&sll=34.741612,-95.625&sspn=68.827616,113.203125&ie=UTF8&ll=41.109365,24.535217&spn=0.512179,0.884399&t=p&z=10
>>
>> How much is the radius you picked when considering nearby cities? Is
>> it more than 50Km?
>
> It's exactly 50km. That may need adjusting. (If we lower it, than some
> of those cities will just go away entirely; it always uses the closest
> weather station for a city, so the fact that those cities use the LGKV
> code means there isn't any other weather station closer to them than that.)
>
> (In this case, Chrysoúpolis is listed because that's where the LGKV
> weather station actually is, and Dráma, Kavála and Xánthi are listed
> because they're marked as being the capitals of states/provinces/
> whatever-you-call-them-in-Greece in our dataset, which is one of the
> things we use to guess that a city is a major city that should be listed.)
>
>> c. In some cases, the transliterated version does not have an accent.
>> For example,
>>
>> Chrysoúpolis Airport and
>> Chrysoupoli Airport
>>
>> It looks as if the airport name of the original entry gets the
>> transliteration, while the nearby cities do not get transliteration of
>> the airport name.
>
> Hm... yeah, that's a bug ("Chrysoupoli Airport" is the original weather
> station name from the METAR source file, "Chrysoúpolis Airport" is
> obviously the more-fixed-up version). But in this case it doesn't
> matter, because that string never gets displayed in the UI. (You'll note
> that neither version shows up in the .po file.) The METAR source strings
> only get used in cases where there is more than one weather station in a
> city (which doesn't seem to be the case for anywhere in Greece).
>
> -- Dan
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Gimp traslations

[Simos Xenitellis]

On Tue, Aug 5, 2008 at 5:45 AM, Khoem Sokhem <[EMAIL PROTECTED]> wrote:
> On Monday 04 August 2008 18:33:47 Christian Rose បានសរសេរ ៖
>> On 7/10/08, Claude Paroz <[EMAIL PROTECTED]> wrote:
>> > Le jeudi 10 juillet 2008 à 08:20 +0200, Sven Neumann a écrit :
>> > > Hi,
>> > >
>> >  > On Wed, 2008-07-09 at 10:23 +0200, Claude Paroz wrote:
>> >  > > The Khmer translation team currently only translates Gimp in the
>> >  > > GTP. http://l10n.gnome.org/teams/km
>> >  > >
>> >  > > I doubt that an SVN account will be given when the translation
>> >  > > effort concerns only one application, even if it is a great
>> >  > > application :-)
>> >  >
>> >  > Why not? I don't quite follow this argument. You are making the work
>> >  > of the Khmer translators more difficult without a good reason. It is
>> >  > very unlikely that they will start to work on other applications if
>> >  > that means that they have to ask the developers of those applications
>> >  > to commit their work. As far as I can see, Khoem has been doing a very
>> >  > good job so far. So please give him an SVN account.
>> >
>> > Just to make things clear, I'm not in a position to decide this. I'm not
>> >  member of account team, neither GTP spokesperson. It was only my
>> >  opinion.
>> >
>> >  So Khoem is free to ask an account through [EMAIL PROTECTED]
>> >
>> >
>> >  Claude
>>
>> Khoem now has a SVN account; 'khem'. Hope to see many more Khmer GNOME
>> translations now, in addition to the nice Gimp ones. :-)
>
> Thank you very much for your help.
> Could you please give me the link to check out the gimp from from svn as an
> example for the next module beside the gimp module?

Hi Sokhem,
General instructions for SVN for translators is at
http://live.gnome.org/TranslationProject/SvnHowTo

When you visit
http://svn.gnome.org/viewvc/
you can see all programs that are developed on the GNOME Network.
GIMP is included, therefore, you can use the command from the "General
instructions" that looks like

svn co svn+ssh://[EMAIL PROTECTED]/svn/[module]/trunk [module]

and in your case you would put

svn co svn+ssh://[EMAIL PROTECTED]/svn/gimp/trunk my-gimp-checkout

A folder called "my-gimp-checkout" will be created with the source
code. You can use any name for the folder.

In some cases, especially when GNOME is about to be released, the
projects are split in "branches". You can find whether you have a
"branch" or the "trunk" (aka "HEAD"), when you visit
http://l10n.gnome.org/languages/km/gnome-extras
and you put the mouse on the link of the files. A tooltip will appear
that shows whether you need the "HEAD" or a branch. Then, you follow
the above instructions accordingly.

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Gimp traslations

[Simos Xenitellis]

On Thu, Aug 7, 2008 at 3:15 AM, Khoem Sokhem <[EMAIL PROTECTED]> wrote:
> Thanks for your useful help.
> But now I forgot my password, I try to checkout gimp module but it asks for
> password.
> Could you please help me about this?

Hi,

When you got your new your new account "khem", did you generate a
suitable "SSH key pair" according to the instructions in
http://live.gnome.org/NewAccounts ?

When you generate an "SSH key pair", the program creates two files.
You put one file at the GNOME Account registration page (Mango), and
the other file, "id_rsa.pub", you need to put it in your home
directory, inside the ".ssh/" subdirectory. You have to do this step,
and you need to keep "id_rsa.pub" safe because it links you with the
other key you have put at Mango on GNOME. If you install Linux again,
you need to take backup of the "id_rsa.pub" file.

Before you type "svn co svn+ssh://...", it is good to type first

ssh-add

This command will search into your home directory, search into ".ssh",
and find the id_rsa.pub. It will ask for the password to unlock the
file. You must put here the password that you used during the "SSH key
pair" generation. If you put it here, then the next commands (svn co
svn+ssh://...) will not ask you again about passwords until you close
the Terminal window.

If you tried this and you really forgot the password, then you can ask
to make a new "SSH key pair".

All the best,
Simos

>
> Thank again.
> Khoem Sokhem
>
> On Tuesday 05 August 2008 4:26:17 pm Simos Xenitellis បានសរសសេរ ៖
>> On Tue, Aug 5, 2008 at 5:45 AM, Khoem Sokhem <[EMAIL PROTECTED]>
> wrote:
>> > On Monday 04 August 2008 18:33:47 Christian Rose បានសរសេរ ៖
>> >
>> >> On 7/10/08, Claude Paroz <[EMAIL PROTECTED]> wrote:
>> >> > Le jeudi 10 juillet 2008 à 08:20 +0200, Sven Neumann a écrit :
>> >> > > Hi,
>> >> > >
>> >> >  > On Wed, 2008-07-09 at 10:23 +0200, Claude Paroz wrote:
>> >> >  > > The Khmer translation team currently only translates Gimp in the
>> >> >  > > GTP. http://l10n.gnome.org/teams/km
>> >> >  > >
>> >> >  > > I doubt that an SVN account will be given when the translation
>> >> >  > > effort concerns only one application, even if it is a great
>> >> >  > > application :-)
>> >> >  >
>> >> >  > Why not? I don't quite follow this argument. You are making the
>> >> >  > work of the Khmer translators more difficult without a good reason.
>> >> >  > It is very unlikely that they will start to work on other
>> >> >  > applications if that means that they have to ask the developers of
>> >> >  > those applications to commit their work. As far as I can see, Khoem
>> >> >  > has been doing a very good job so far. So please give him an SVN
>> >> >  > account.
>> >> >
>> >> > Just to make things clear, I'm not in a position to decide this. I'm
>> >> > not member of account team, neither GTP spokesperson. It was only my
>> >> > opinion.
>> >> >
>> >> >  So Khoem is free to ask an account through [EMAIL PROTECTED]
>> >> >
>> >> >
>> >> >  Claude
>> >>
>> >> Khoem now has a SVN account; 'khem'. Hope to see many more Khmer GNOME
>> >> translations now, in addition to the nice Gimp ones. :-)
>> >
>> > Thank you very much for your help.
>> > Could you please give me the link to check out the gimp from from svn as
>> > an example for the next module beside the gimp module?
>>
>> Hi Sokhem,
>> General instructions for SVN for translators is at
>> http://live.gnome.org/TranslationProject/SvnHowTo
>>
>> When you visit
>> http://svn.gnome.org/viewvc/
>> you can see all programs that are developed on the GNOME Network.
>> GIMP is included, therefore, you can use the command from the "General
>> instructions" that looks like
>>
>> svn co svn+ssh://[EMAIL PROTECTED]/svn/[module]/trunk [module]
>>
>> and in your case you would put
>>
>> svn co svn+ssh://[EMAIL PROTECTED]/svn/gimp/trunk my-gimp-checkout
>>
>> A folder called "my-gimp-checkout" will be created with the source
>> code. You can use any name for the folder.
>>
>> In some cases, especially when GNOME is about to be released, the
>> projects are split in "branches". You can find whether you have a
>> "branch" or the "trunk" (aka "HEAD"), when you visit
>> http://l10n.gnome.org/languages/km/gnome-extras
>> and you put the mouse on the link of the files. A tooltip will appear
>> that shows whether you need the "HEAD" or a branch. Then, you follow
>> the above instructions accordingly.
>>
>> Simos
>
>
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Gimp traslations

[Simos Xenitellis]

On Thu, Aug 7, 2008 at 10:00 AM, Khoem Sokhem <[EMAIL PROTECTED]> wrote:
> On Thursday 07 August 2008 3:36:10 pm Simos Xenitellis បានសរសសេរ ៖
>> On Thu, Aug 7, 2008 at 3:15 AM, Khoem Sokhem <[EMAIL PROTECTED]>
> wrote:
>> > Thanks for your useful help.
>> > But now I forgot my password, I try to checkout gimp module but it asks
>> > for password.
>> > Could you please help me about this?
>>
>> Hi,
>>
>> When you got your new your new account "khem", did you generate a
>> suitable "SSH key pair" according to the instructions in
>> http://live.gnome.org/NewAccounts ?
>>
>> When you generate an "SSH key pair", the program creates two files.
>> You put one file at the GNOME Account registration page (Mango), and
>> the other file, "id_rsa.pub", you need to put it in your home
>> directory, inside the ".ssh/" subdirectory. You have to do this step,
>> and you need to keep "id_rsa.pub" safe because it links you with the
>> other key you have put at Mango on GNOME. If you install Linux again,
>> you need to take backup of the "id_rsa.pub" file.
>>
>> Before you type "svn co svn+ssh://...", it is good to type first
>>
>> ssh-add
>>
>> This command will search into your home directory, search into ".ssh",
>> and find the id_rsa.pub. It will ask for the password to unlock the
>> file. You must put here the password that you used during the "SSH key
>> pair" generation. If you put it here, then the next commands (svn co
>> svn+ssh://...) will not ask you again about passwords until you close
>> the Terminal window.
>>
>> If you tried this and you really forgot the password, then you can ask
>> to make a new "SSH key pair".
>
> Oop! I know the problem with this, Because of I install new linux (openSUSE)
> without backing up that file. So Have I to make a new SSH key pair again?
> How careless am I?
>
> Thanks for your helpful idea.

If you have your Mango account details, at
http://live.gnome.org/NewAccounts
it says that you can add a few more SSH key-pairs.
This should help.

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Gimp traslations

[Simos Xenitellis]

2008/8/7 Wouter Bolsterlee <[EMAIL PROTECTED]>:
> 2008-08-07 klockan 10:36 skrev Simos Xenitellis:
>> When you generate an "SSH key pair", the program creates two files.
>> You put one file at the GNOME Account registration page (Mango), and
>> the other file, "id_rsa.pub", you need to put it in your home
>> directory, inside the ".ssh/" subdirectory. You have to do this step,
>> and you need to keep "id_rsa.pub" safe because it links you with the
>> other key you have put at Mango on GNOME. If you install Linux again,
>> you need to take backup of the "id_rsa.pub" file.
>
> Eh, it's the other way around. The .pub file is public, the other is NOT. If
> you EVER provide your private key (id_rsa without .pub) to someone else (or
> paste it into Mango) then you should consider your key compromised and NEVER
> use it again. NEVER EVER share your private key. Keep it safe (and warm) at
> all times on a trusted medium. Additoinally you REALLY SHOULD have a
> passphrase on your private key, so that the file itself is not directly
> usable. Ssh-agent (or seahorse-agent) caches the passphrase anyway, so you
> only have to type it once. The security benefits are MAJOR.
>
> Again, NEVER provide your private key to someone else.

Yes, you are right! I mixed up my keys.

In any case, the documentation at http://live.gnome.org/NewAccounts
stands solid.

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Non-community-based approaches to localisation

[Simos Xenitellis]

2008/9/7 Sri Ramadoss M <[EMAIL PROTECTED]>:
> On Wed, Sep 3, 2008 at 1:10 PM, Gora Mohanty <[EMAIL PROTECTED]> wrote:
>>
>> 1. I know of no attempt to contact existing language
>>   teams prior to starting on this work. This is true
>>   at least of Bengali, Hindi, Malayalam, and Oriya.
>>   Worse yet, the language team line in the .po file
>>   header has been changed to some CDAC address, which
>>   can only lead to myriad problems down the road.
>
> Its the case with Tamil too.
>
>
>>
>> Would like to hear your views.
>>
>
> I am not sure why so much of effort is put unnecessarily, when doors of the
> community are always open even to them.

The part that I think that is surprising is that a big organisation
(in this case C-DAC), took the initiative to put resources to carry
out large-scale open-source localisation.
I am not sure if I speak alone here, I would be delighted if I saw a
similar attempt for my mother tongue. Even a limited, crude attempt,
or a just sign of interest would be great for my case.

The fact that the open-source l10n communities in India were not
consulted before the C-DAC localisation work, looks to me as a common
mistake, and does not surprise me. The way that open-source
communities work is just too different, and you can expect such
issues.

What I see that was missing and still is, is a person to act as
liaison between the open-source localisation communities of India and
C-DAC. I took up somewhat this role during the discussion some months
ago, but it just looks awkward for me to be further involved.
Could someone pick up this task?

What you have in hand is that there is a big organisation which showed
interest some months ago with l10n, and it might still have interest
in open-source localisation. It's up to you to lead the way with
C-DAC, in localisation or other open-source activities.

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Receiving SVN commits mails relating to localisation

[Simos Xenitellis]

Hi All,

I am trying to implement a way to receive notifications for SVN
commits to GNOME SVN, for specific users.
These are the translators, and I want the notifications to get
forwarded to our mailing list.
The goal is, once an SVN commit takes place, a notification (from
svn-commits mailing list) is forwarded to the mailing list.
The commits of specific people only are forwarded.

What I have achieved so far:
1. Subscribe to svn-commits mailing list with your GMail account.
Select to receive all notifications.
2. Add a filter (in GMail) so that e-mail that contain the username of
the specific few committers
gets forwarded to your mailing list. The rest of the e-mails are deleted.

The problem is that a mailman mailing list does not allow to accept
mail with implicit destination (BCC),
so these mails are held in the moderation queue.

It is possible to use procmail, however this is not available at our webhosting.

Is there an easy alternative, such as
1. A service that allows to forward e-mails while rewriting the
destination e-mail address?
2. A feature at gnome.org that allows to receive notifications
pertaining to specific usernames only?

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Receiving SVN commits mails relating to localisation

[Simos Xenitellis]

Thanks Olav, it worked.

The require_explicit_destination option is found under Privacy
Options/Recipient Filters in mailman.

A less complicated alternative would be to pick the RSS feeds that
cia.cx produces, and then find an RSS to Email service. This does not
produce 'realtime' notifications due to delays at cia.cx, but it's
reasonable. If someone goes this way, it would be good to document
which rss2email service they chose.

Simos

On Sun, Oct 5, 2008 at 2:54 PM, Olav Vitters <[EMAIL PROTECTED]> wrote:
> On Sat, Oct 04, 2008 at 06:52:40PM +0100, Simos Xenitellis wrote:
>> The problem is that a mailman mailing list does not allow to accept
>> mail with implicit destination (BCC),
>> so these mails are held in the moderation queue.
>
> Change the require_explicit_destination setting.
>
> --
> Regards,
> Olav
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Cultural Issue with the Foot Logo

[Simos Xenitellis]

On Fri, Oct 31, 2008 at 3:48 AM, Andre Klapper <[EMAIL PROTECTED]> wrote:
> Am Freitag, den 31.10.2008, 09:56 +0700 schrieb Theppitak
> Karoonboonyanan:
>> How about this one?
>>   http://linux.thai.net/~thep/shots/gnome-logo/gnome-ok.svg
>> (Sorry, this one is the real ugly.)
>>
>> Hopefully it's not an offensive sign in some culture. ;-)
>
> http://en.wikipedia.org/wiki/Hand_gesture#Okay
> It can be quite offensive in Brazil (Mexico and Paraguay were also
> mentioned in one article I've found, don't know).

Apparently it's offensive to all Latin America.
The story goes that when Richard Nixon visited a Latin American
country, there were hundreds of local government officials waiting at
the tarmac, with red carpet and all.
Nixon appears from the airplane, raises both arms, smiles broadly and
does that gesture to them with each hand.

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Cultural Issue with the Foot Logo

[Simos Xenitellis]

Hi Theppitak,

As already suggested, delegating the choice of the new logo to the Art
Team is the typical thing to do.

My concern is in the practicalities when trying to apply the new logo
in a distribution.
If you have your own distribution, you can make all sort of changes,
so it it OK.

What you might want to explore is how to make the logo theme-able.
That is, you can select a theme that would alter the logo in all
places in GNOME.
You can then create a package with this cut-down logo-changing theme
that a user can either install on demand, or it is installed
automatically when the user selects, for example, Thai support.

Assuming that it is possible to change the logo through theming, you
may then choose a logo that has a special meaning to SE Asia.

Simos

On Thu, Nov 6, 2008 at 12:56 PM, Theppitak Karoonboonyanan
<[EMAIL PROTECTED]> wrote:
> On Thu, Nov 6, 2008 at 6:51 PM, Calum Benson <[EMAIL PROTECTED]> wrote:
>>
>> On 6 Nov 2008, at 10:37, Theppitak Karoonboonyanan wrote:
>>
>>> In my vague memory, some GNOME 1.x versions used to use a flower
>>> logo at the main menu. And after some search, I've found some
>>> evidences:
>>
>> Ah yes.  During our GNOME 1.2 usability study, some of our participants
>> memorably asked "what's the fried egg for?" :)
>
> I see. It looks pretty much like a fried egg, too. :-)
>
>> Other than that, a (well-designed) flower might be a pretty good call-- it
>> has some history in GNOME, and it symbolises all those hippie values that
>> are shared by the open source community :)
>
> Probably, elongating the petals helps?
>
> Before:
>  http://linux.thai.net/~thep/shots/gnome-logo/flower-1.4.svg
>
> After:
>  http://linux.thai.net/~thep/shots/gnome-logo/flower-long.svg
>
> --
> Theppitak Karoonboonyanan
> http://linux.thai.net/~thep/
> --
> marketing-list mailing list
> [EMAIL PROTECTED]
> http://mail.gnome.org/mailman/listinfo/marketing-list
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Download po files in a tar.gz

[Simos Xenitellis]

Thanks for the feature Claude.

One issue I have in mind is to add the download date in the filename
of the archives.
For exampe,
instead of
http://l10n.gnome.org/languages/el/gnome-2-24/ui.tar.gz
to have something like

http://l10n.gnome.org/languages/el/gnome-2-24/gnome-2-24-ui-2008-11-04.tar.gz

This would be good for archiving purposes.

Simos

On Thu, Nov 13, 2008 at 7:57 PM, Claude Paroz <[EMAIL PROTECTED]> wrote:
> Hi,
>
> For your information, I've added the possibility to download all po
> files (tar.gz) for a specific language and release (doc and ui
> separated) on l10n.gnome.org.
> You'll find the link at the bottom ot the "language release" pages.
> See e.g. http://l10n.gnome.org/languages/fi/gnome-2-24/
>
> I also took advantage to rename po files for help, which were often
> uniformely named help...po. They contain now the name of
> the application, e.g. eog-help.HEAD.fr.po
>
> HTH,
>
> Claude
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Translation files need to be comitted!!

[Simos Xenitellis]

On Fri, Nov 21, 2008 at 11:01 AM, Zabeeh Khan <[EMAIL PROTECTED]> wrote:
> Hii all,
>
> I have attached some translated .po files to
> http://bugzilla.gnome.org/show_bug.cgi?id=561788
>
> Someone please commit them.

The translations have been committed.

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Yoruba, Hausa and Igbo (yo, ha, ig)

[Simos Xenitellis]

On Tue, Dec 16, 2008 at 1:47 PM, Thomas Thurman  wrote:
> 2008/12/16 Simos Xenitellis :
>> I think it would be good to get the views of the people behind Wazobia
>> Linux, so that to give a chance to work upstream with GNOME for the
>> translations.
>> Is anyone already in contact, or is this task open?
>
> Nobody is in contact-- what I've posted is all anyone here knows, as
> far as I know.  distrowatch.com claims that Wazobia is dormant:
> http://distrowatch.com/table.php?distribution=wazobia
>
> I'll try emailing one of the contact addresses and see what happens.
> Does anyone have an existing form letter that I can base it on?

Personally I would opt for an informal first email, just to elicit a
reply before going into details.
Wazobia Linux was released about 3 years ago,
http://lists.kabissa.org/lists/archives/public/a12n-forum/msg00439.html

Sample e-mail:

"Hi,
I am a member of the GNOME Translation Project (www.gnome.org) where
we translate the open-source GNOME Desktop Environment in over 160
languages,
http://l10n.gnome.org/languages/

I found your e-mail address from xyz.

We recently found out that GNOME has been translated to three Nigerian
languages by the Wazobia project, for Wazobia Linux.

I am trying to find more information about those translations in order
to help the GNOME translations for Yoruba, Hausa and Igbo.

Do you know who I should ask for more regarding the translations?
I am interested to find out if there are any newer translation efforts,
and work out how to add any existing translations in GNOME.

Thanks,
Thomas"

If direct contact does not bring a reply, then contacting through
other people that are involved in African languages L10n would be
good.

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Yoruba, Hausa and Igbo (yo, ha, ig)

[Simos Xenitellis]

2008/12/16 Johannes Schmid :
> Hi!
>
> I think this will end up again in the discussion if a translation can be
> considered a "derived work". We had this discussion for the license used
> in launchpad some while back.
>
> I think it's best to ask Luis Villa about it before putting the things
> in svn.

I think it would be good to get the views of the people behind Wazobia
Linux, so that to give a chance to work upstream with GNOME for the
translations.
Is anyone already in contact, or is this task open?

Simos

> Am Dienstag, den 16.12.2008, 00:29 -0500 schrieb Thomas Thurman:
>> Further to my discussion on
>> http://blogs.gnome.org/tthurman/2008/12/15/i-think-we-should-have-an-igbo-translation/#comments
>>
>> in which I mentioned that a Nigerian distro called Wazobia Linux has
>> translated various GNOME applications into the three languages in the
>> subject line, a user has found a disk image, extracted the .mo files,
>> decompiled them to .po and sent them to me.  I have reproduced the
>> archive and the files here temporarily for easy access:
>>
>> http://www.gnome.org/~tthurman/yo-ha-ig/
>>
>> Must these translations have been released under a Free licence?
>> What do we have to do in order to merge them upstream?
>>
>> Thomas
>>
>>
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-i18n
>
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: New release of Damned Lies with Vertimus included

[Simos Xenitellis]

On Sun, Jan 4, 2009 at 10:44 PM, Og Maciel  wrote:
> Confirmed. I too have received several emails already but wonder if it
> has to do with my committer access (in other words, do people who send
> in their translations also get the email when it gets committed?)

I have not received such a CC: to my personal account but rather they
are sent only to the mailing list.

An important issue is that the e-mail you have put in
Vertimus+DamnedLies should be the same as the email you registered to
the mailing list. Otherwise those notifications may not get through.

Personally I would prefer those notifications to have the Sender:
field set to something generic such as 'l10n-mana...@gnome.org', so
that it is possible to add a single e-mail account to the mailing list
members.

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: New release of Damned Lies with Vertimus included

[Simos Xenitellis]

On Mon, Jan 5, 2009 at 6:34 PM, Jonh Wendell  wrote:
> Em Seg, 2009-01-05 às 11:12 +0100, Claude Paroz escreveu:
>
>> I've just committed the modification. Now the mail is sent from the
>> "gnome...@gnome.org" address. Mailing list administrators, you should
>> allow this address to post on your list if you want to receive
>> notifications.
>>
>> Claude
>
> [a bit off-topic]
>
> Hi. Where in Mailman is that option?

You can add the gnome...@gnome.org e-mail using the Mass Subscription
option in Mailman.
Then, find this e-mail in the member list and select not to receive any e-mails.
That should be it.

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: NetworkManager Translation submissions

[Simos Xenitellis]

Hi,

In such cases, the common thing is to file bug reports to add the translations.
There are currently two pending,
http://bugzilla.gnome.org/show_bug.cgi?id=566372
http://bugzilla.gnome.org/show_bug.cgi?id=565286

However, it would be better to have the thoughts of the maintainer on
this as well.

Dan, how would you like to receive translations to NetworkManager (from git)?

Simos

On Tue, Jan 6, 2009 at 9:07 AM, Runa Bhattacharjee  wrote:
> Hello,
>
> After the NetworkManager source moved to git.freedesktop.org[1], I can't
> seem to find any information about where to submit the translations. The
> .pot file available through l10n.gnome.org is also from the day of the
> move[2].
>
> Can someone please point me to any announcements/documentation that I might
> have missed?
>
> Thanks a lot
>
> regards
> Runa
>
> [1] http://cia.vc/stats/project/gnome/NetworkManager/.message/40e109
> [2] http://l10n.gnome.org/POT/NetworkManager.HEAD/NetworkManager.HEAD.pot
> --
> blog: http://runab.livejournal.com
> irc: mishti or runa_b on Freenode
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

What can Git do for translators?

[Simos Xenitellis]

Hi All,

There is a discussion on the gnome developer mailing lists regarding a
possible move
from Subversion (SVN) to a Distributed Version Control System (DVCS)
such as git, which is already used for the Linux kernel, Perl, some
libraries such as clutter.
This post is to help contribute to the discussion.

If you are a GNOME Foundation member, you probably got a survey e-mail
in December on the issue.

The survey results are at
http://blogs.gnome.org/newren/2009/01/03/gnome-dvcs-survey-results/
http://mces.blogspot.com/2009/01/gnome-dvcs-survey.html

The GNOME dev discussion takes place at
http://mail.gnome.org/archives/desktop-devel-list/2009-January/thread.html#3
The discussion is somewhat heated, so it's no place for translators to
post about.

If a move eventually takes place, it will require time and effort, so
it would not happen within the next six months.

Moving from Subversion (SVN) to a DVCS such as git will have lots of
benefits for the developers, which is very important. Normally, we
expect the KDE project to try these things out first but this time it
appears they are sticking with SVN.

In general, learning a DVCS such as git is a new modern skill. There
are books available,
http://book.git-scm.com/ and you can try it out with a free repository
(100MB) at https://github.com/ or at Gitorious, http://gitorious.org/

The big question is, how would a DVCS affect the GNOME localisation workflows?
Are we going to keep the same easy facilities? Is a DVCS going to make
some things easier?
Is there another big project which supports localisation to many
languages, and it uses a DVCS?

Scenario A
=> Using command line tools, we add a translation to the main repository.

Assume the repository is git://git.gnome.org/gnome-games.git
we make a local copy by 'cloning' the repository ('checkout' is
something different in git)

git clone git://git.gnome.org/gnome-games.git

This would create a very big tree, because it would make a full
offline copy, with all the history for the last ten years or so. When
we use SVN, a checkout of gnome-games is 124MB. The approximate size
of a 'git clone' should be quite larger. My test with 'git-svn clone'
was not conclusive (due to the way it works, it is very slow, I
stopped after an hour, which it downloaded 74MB).

It might be possible to use the --depth parameter in 'git clone',
which can limit how far back the history will go to. Reading the man
page for git-clone, it is not clear if we would be able to 'push' (or
'commit' per SVN) the changes back to the tree.

   --depth 
   Create a shallow clone with a history truncated to the
specified number of revisions. A shallow repository has a number of
limitations (you
   cannot clone or fetch from it, nor push from nor into it),
but is adequate if you are only interested in the recent history of a
large project
   with a long history, and would want to send in fixes as patches.

Scenario B
damned-lies and vertimus should be rather easy to convert to git,
since they would simply need to replace 'svn checkout' with 'git clone
--depth 0'.
Is that the case?

Are there any other issues we need to think about?

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: What can Git do for translators?

[Simos Xenitellis]

On Wed, Jan 7, 2009 at 11:32 PM, Leonardo F. Fontenelle
 wrote:
> Em Qui, 2009-01-08 às 00:23 +0100, Axel Hecht escreveu:
>> Jumping in to this discussion at some random point:
>>
>> I think that DVCSes can add value to localizers. In particular for
>> projects that have in-development l10n, but probably for other
>> projects, too.
>>
>> The main value a DVCS gives to localizers is coming from exposing the
>> history of the original language, though. I can see good value in
>> exposing localizable strings to the localizer in changesets as they
>> were added to the original language, as they're likely going to belong
>> to the same context. So while going through a file of localizable
>> strings from top to bottom, you would have to go through several
>> context switches, going through the localizable strings patch-wise
>> might come with less contex switches.
>>
>> That of course is more of a job and an opportunity for translation
>> tools than anything else.
>>
>
> At least with GNU Gettext, running msgmerge will move translations from
> one line to another without hesitation, and automatic comments are
> always there to add noive to diffs. If any dcvs can work around this
> adversities, I'll defend its adoption. Today, if I need to read a diff
> between message catalogs, I run "msgcat file.po -o file.po" (because
> some translators use poEdit), then msgmerge between both of them and the
> same POT, or usually between the oldest and the newest (from DL), and
> only then I can get a readable diff.

Off-topic, po-diff related.
There is podiff that allows to diff two po files.

It produces output that looks like

---
Modified Message:
'Iagno Manual V2.8'
Old:
'Τεκμηρίωση του Ιάγνος, έκδοση 2.7'
New:
'Τεκμηρίωση του Ιάγνος, έκδοση 2.8'


Available from
https://edge.launchpad.net/podiff

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: What can Git do for translators?

[Simos Xenitellis]

On Thu, Jan 8, 2009 at 1:19 AM, Shaun McCance  wrote:
> Hi Simos,
>
> I don't want to detract from this conversation, because I think
> it's important to consider how this would impact all of Gnom's
> contributors, including translators, documentation folks, etc.
> A switch would have at least some impact on everybody, and we
> need to know how to deal with problems.
>
> But...
>
>> Scenario A
>> => Using command line tools, we add a translation to the main repository.
>>
>> Assume the repository is git://git.gnome.org/gnome-games.git
>> we make a local copy by 'cloning' the repository ('checkout' is
>> something different in git)
>>
>> git clone git://git.gnome.org/gnome-games.git
>>
>> This would create a very big tree, because it would make a full
>> offline copy, with all the history for the last ten years or so. When
>> we use SVN, a checkout of gnome-games is 124MB. The approximate size
>> of a 'git clone' should be quite larger. My test with 'git-svn clone'
>> was not conclusive (due to the way it works, it is very slow, I
>> stopped after an hour, which it downloaded 74MB).
>
> I want to first point out that it's slow because it's git-svn.
> I don't want people to think it would be this terribly slow if
> we were using git.  Cloning from a git server is quite fast.
>
> More importantly, you'd be surprised at just how small a git
> clone actually is.  I have both a git clone and an svn checkout
> of gnome-doc-utils.  The svn checkout is 38MB.  The git clone
> is 26MB.  Seriously, it's smaller.  And the git clone has more
> commits that aren't in SVN yet.

Hi Shaun,

This is the kind of information we need. That a possible move to git
will not cause issues with the current translation practices.

Therefore, for a coordinator that wants to update a translation the
manual way, the steps would be something like

1. Get a copy of the repository for the package (i.e. gnome-games)
$ git clone git://git.gnome.org/gnome-games.git
Initialized empty Git repository in /tmp/gnome-games/.git/
remote: Counting objects: 8728, done.
remote: Compressing objects: 100% (8712/8712), done.
remote: Total 8728 (delta 3431), reused 0 (delta 0)
Receiving objects: 100% (8728/8728), 71541.07 KiB | 239 KiB/s, done.
Resolving deltas: 100% (431/431), done.
$ _

2. Update the translation
$ cd gnome-games/po
$ intltool-update  el


3. Commit first the translation to the local copy of the repository.
$ git commit -a -m "Updated my translation"
Created commit 22783ff: Updated translation.
 1 files changed, 1 insertions(+), 0 deletions(-)
$ _

4. Push the change to the remote repository at git.gnome.org
$ git push
Counting objects: 5, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 316 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
To g...@git.gnome.org:simos/gnome-games.git
   ff4bf15..22783ff  el -> el
$ _

5. That's it!

A practical comparison between git and other DVCSs (and SVN) is at
http://www.whygitisbetterthanx.com/

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: What can Git do for translators?

[Simos Xenitellis]

On Fri, Jan 9, 2009 at 12:19 AM, Federico Mena Quintero
 wrote:
> On Tue, 2009-01-06 at 15:24 +0000, Simos Xenitellis wrote:
>
>> The GNOME dev discussion takes place at
>> http://mail.gnome.org/archives/desktop-devel-list/2009-January/thread.html#3
>> The discussion is somewhat heated, so it's no place for translators to
>> post about.
>
> The "real" discussion about how the migration is being done is in
> gnome-infrastructure:
> http://mail.gnome.org/archives/gnome-infrastructure/2009-January/thread.html
>
> And our scratchpad is here:
> http://live.gnome.org/GitMigration
>
>> If a move eventually takes place, it will require time and effort, so
>> it would not happen within the next six months.
>
> We hope to have working repositories, at least for guinea pigs, within
> two weeks :)  Moving all the repositories over to git will of course
> require time --- it's not the conversion that is the biggest problem,
> but fixing the infrastructure and writing documentation.
>
>> The big question is, how would a DVCS affect the GNOME localisation 
>> workflows?
>
> One of my tasks for the migration to Git is to write a little bunch of
> tutorials for various scenarios --- maintainers, contributors,
> translators, etc.
>
> However, I'm not 100% sure about the workflows that translators tend to
> use.  Do people mostly use web tools (and what happens then --- does the
> tool commit for them)?  Or do they checkout a whole module and simply
> commit to the .po files?  Or do they checkout a *single* .po file and
> then commit it back, or send patches to a language coordinator?

Currently, the web tools do not commit translations for the
translators in GNOME i18n.

Thus, what translators with SVN access do is
1. Checking out a full module and committing the translation (after
running 'intltool-update LL', which updates the translation to the
latest version of the code)
2. Checking out just the po/ subdirectory and committing the translation.

It is not common to send patches of PO files for committing because
the reference files provided from damned-lies may change at any time
when new translation strings are added.

The Translation Project (http://translationproject.org/) has (for many
years now) an automated system where you send the translation file as
an e-mail attachment and it adds it for you to a common location of
translation files.

Something that would be desirable with GNOME translations would be to
able to make easily changes across all the translations of a language,
and then commit the files in an easy way.
In KDE, all translations for a specific language reside in a separate
directory tree, which makes it easy to make overall changes. I think
the KBabel/Lokalize tool has an option to allow to view all the
translations in a single list, so that one can identify discrepancies
in similar terms.
The same tool has an option to commit (SVN) the translations from
within the GUI.

Reading about 'git submodule' at
http://book.git-scm.com/5_submodules.html it looks it might be good to
try this feature in order to separate the translations from the code
in each repository.

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: What can Git do for translators?

[Simos Xenitellis]

On Fri, Jan 9, 2009 at 10:35 AM, Leonardo F. Fontenelle
 wrote:
> Em Sex, 2009-01-09 às 03:27 +0000, Simos Xenitellis escreveu:
>>
>> The Translation Project (http://translationproject.org/) has (for many
>> years now) an automated system where you send the translation file as
>> an e-mail attachment and it adds it for you to a common location of
>> translation files.
>>
>> Something that would be desirable with GNOME translations would be to
>> able to make easily changes across all the translations of a language,
>> and then commit the files in an easy way.
>> In KDE, all translations for a specific language reside in a separate
>> directory tree, which makes it easy to make overall changes. I think
>> the KBabel/Lokalize tool has an option to allow to view all the
>> translations in a single list, so that one can identify discrepancies
>> in similar terms.
>> The same tool has an option to commit (SVN) the translations from
>> within the GUI.
>>
>> Reading about 'git submodule' at
>> http://book.git-scm.com/5_submodules.html it looks it might be good to
>> try this feature in order to separate the translations from the code
>> in each repository.
>>
>
>
> I hope the submodule feature works for us.
>
> I don't like the KDE approach (even if KDE translators don't seem to
> bother having scripts changing PO files in the repository), and it works
> best with a policy of giving SVN accounts to most regular translators
> (that would be circa 10 in my team).
>
> The TP-Robot approach might work most of the time, if it can receive
> screenshots as well. Same for an Web-based approach (e.g. Damned Lies).
>
> There are some translations which are not in PO files or in screenshots;
> e.g. the welcome mail in Evolution. If we get a simple "commit"
> interface like TP-Robot or Transifex, then we will need to decide
> between keeping translators with commit access or handling exceptional
> translations (like the welcome mail) via bug reports.

I think the wording here would be that teams would continue to have
commit access (in the same sense that developers commit code), and
that it is desirable to have some additional automated way, either
through the web or by email or even through gtranslator, for those
translators that wish to, to add their translations.

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Using Git and separating translations into their own l10n-LL repository

[Simos Xenitellis]

Hi All,

This is a long-ish post regarding the migration to Git and
what we can do to make l10n a bit better.

Here I suggest to use the 'git submodule' support
so that the translation material for each language
reside in a single repository.
Comments would be appreciated.
If all is fine, I'll put this, with more details, to live.gnome.org.

When splitting the l10n files from each module, there is a choice to either
1. create a companion repository for each module (for example, for
mousetweaks, create 'mousetweaks-l10n')
that will hold all localisation files for all languages, for this module.
If we have 1000 modules, there would be 1000 additional companion l10n modules.
2. create a repository for each language, and this repository will
contain all localisation files for all modules.
If we have 1000 modules, there would be just 160 additional l10n
repositories (it's one new repository per language).

The right choice appears to be to create one repository per language.
There are many reasons which can be discussed if deemed necessary.

The rest of the e-mail shows how the separated repositories look like.
I used as an example the mousetweaks and vinagre modules, for the el,
es, fr and sv languages.
Both have help/ and po/ subdirectories with l10n material.
You can fork the generated (six) repositories from
http://github.com/simos/ if you want to try them out.

STRUCTURE (l10n-LL)
A language repository name is of the form 'l10n-LL', where LL is the
ISO 639 (-123) language code as usual.
Inside 'l10n-LL' there are directories per module (with the module
name), and further subdirectories 'po/' and 'help/' as necessary.
For example,

l10n-el
├─ mousetweaks
│   ├─ help
│   │   └─ el
│   │   └─ el.po
│   └─ po
│   └─ el.po
└─ vinagre
├─ help
│   └─ el
│   └─ el.po
└─ po
└─ el.po

and

l10n-es
├─ mousetweaks
│   ├─ help
│   │   └─ es
│   │   ├─ es.po
│   │   └─ figures
│   │   ├─ mouse-a11y-add-applet-to-panel-window.png
│   │   ├─ mouse-a11y-dwell-checkbox.png
│   │   ├─ mouse-a11y-dwell-click-type-applet.png
│   │   ├─ mouse-a11y-dwell-click-type-window.png
│   │   ├─ mouse-a11y-dwell-ctw-checkbox.png
│   │   ├─ mouse-a11y-dwell-delay-slider.png
│   │   ├─ mouse-a11y-dwell-gesture-mapping.png
│   │   ├─ mouse-a11y-dwell-mode-choice.png
│   │   ├─ mouse-a11y-dwell-motion-treshold.png
│   │   ├─ mouse-a11y-pointer-capture-context-menu.png
│   │   ├─ mouse-a11y-pointer-capture-locked.png
│   │   ├─ mouse-a11y-pointer-capture-preferences.png
│   │   ├─ mouse-a11y-ssc-checkbox.png
│   │   ├─ mouse-a11y-ssc-delay-slider.png
│   │   └─ mouse-a11y-tab.png
│   └─ po
│   └─ es.po
└─ vinagre
├─ help
│   └─ es
│   ├─ es.po
│   └─ figures
│   └─ vinagre-screenshot.png
└─ po
└─ es.po

STRUCTURE ('l10n' supermodule)
Per git parlance, we create a 'l10n' supermodule, and inside it we add
each language repository as submodules.
Thus,

l10n
├─ README
├─ l10n-el/
├─ l10n-es/
├─ l10n-fr/
└─ l10n-sv/

The above graphic shows the first level of directories.
When we add a new language, the l10n coordinators will add a new entry
here to the new repository 'l10n-LL'.
Each 'l10n-LL' entry is added with 'git submodule add', and points to
a repository created earlier.

STRUCTURE (module)
Now, each module (such as mousetweaks and vinagre) need to simply add
the 'l10n' supermodule.
We remove from help/ and po/ all *.po and figures/ files. For our two
modules, the po/ and help/ subdirectories would look like

mousetweak:
po
├─ LINGUAS
├─ POTFILES.in
└─ POTFILES.skip
help
├─ C
│   ├─ figures
│   │   ├─ mouse-a11y-dwell-checkbox.png
│   │   ├─ mouse-a11y-dwell-click-type-applet.png
│   │   ├─ mouse-a11y-dwell-click-type-window.png
│   │   ├─ mouse-a11y-dwell-ctw-checkbox.png
│   │   ├─ mouse-a11y-dwell-delay-slider.png
│   │   ├─ mouse-a11y-dwell-gesture-mapping.png
│   │   ├─ mouse-a11y-dwell-mode-choice.png
│   │   ├─ mouse-a11y-dwell-motion-treshold.png
│   │   ├─ mouse-a11y-pointer-capture-context-menu.png
│   │   ├─ mouse-a11y-pointer-capture-locked.png
│   │   ├─ mouse-a11y-pointer-capture-preferences.png
│   │   ├─ mouse-a11y-ssc-checkbox.png
│   │   ├─ mouse-a11y-ssc-delay-slider.png
│   │   └─ mouse-a11y-tab.png
│   ├─ legal.xml
│   └─ mousetweaks.xml
├─ Makefile.am
└─ mousetweaks.omf.in

vinagre:
po
├─ LINGUAS
├─ POTFILES.in
└─ POTFILES.skip
help
├─ C
│   ├─ figures
│   │   └─ vinagre-screenshot.png
│   ├─ legal.xml
│   └─ vinagre.xml
├─ Makefile.am
└─ vinagre.omf.in

(mental hint: the C/ folder should actually move to the 'l10n'
supermodule, in 'l10n-C')
We have removed the ChangeLog files as the commits are moved to the submodules.
We have to figure out what to do LINGUAS. Is it possible to remove altogether?

EXAMPLE
This assumes you have the 'git' package ('git-core' if you use
Debian/Ubuntu) installed.

A. Cloning th

Re: Using Git and separating translations into their own l10n-LL repository

[Simos Xenitellis]

On Tue, Jan 13, 2009 at 11:31 PM, Gil Forcada  wrote:
> Hi Simos,
>
> Great explanation, a couple of questions:
>
> - There would be any way to have in a single folder the code and
> translations (aka, the way is right now)? There are some translators
> (I'm counting in) that likes to have the code also.

I am not sure which module you have in mind.
I would say that the idea is, if the translation files are expected to
be managed by damned-lies/l10n.gnome.org, they should reside in the
l10n-LL submodule.

> - The same concern about maintainers forgetting to git pull(?)
> translators is expanded, now they should git pull(?) every single git
> repository (if 160 languages, 160 git pulls(?) before each release).

The 'git submodule update' command, when you run in from the 'l10n'
supermodule,
pulls all the l10n-LL repositories automatically by default.
There is an option to 'git submodule update' to pull individual
language repositories as well.

> Also, if the new DL will have commit functionality (maybe in half a
> year, Claude ... :) and then *all* translations will be committed this
> way, wouldn't be overkill to have all this system?
>
> I mean, if it's a temporal situation that, shouldn't be more productive
> to instead of "wasting" time doing this git submodule thing to provide
> resources and time to get commit functionality to DL that seems to be
> more desired by translators (that's my guess no data actually, just
> supposed so my arguments seems better :D).

I would consider that separating code from localisation files would be
a fundamental improvement rather than a temporary solution.
The issue of manpower to make such changes is the main disadvantage.

It would be easier to provide commit support to damned-lies when
we have separated l10n-LL repositories. Damned-lies would 'auto'-commit
only to designated repositories.

I do not know the details of the SVN hooks and damned-lies. I think
that if a commit/push to a project would call a hook that would invoke
'intltool-update -P' (create POT template file) and store it
somewhere, then damned-lies would not need to clone locally any other
GNOME modules.

To add a few more advantages,
1. Can add access controls for translators to the l10n-LL repositories.
2. It allows translators to make changes across all translations (for
example, change 'widget' in all my translations of GNOME).
3. Pootle could be adapted to perform easier GNOME translation marathons.
4. GTranslator could work as KBabel, it would clone the l10n-LL
repository and would be able to show all translations in a huge sorted
list. This way, similar translations can be easily identified.

>
> El dt 13 de 01 de 2009 a les 23:01 +, en/na Simos Xenitellis va
> escriure:
>> Hi All,
>>
>> This is a long-ish post regarding the migration to Git and
>> what we can do to make l10n a bit better.
>>
>> Here I suggest to use the 'git submodule' support
>> so that the translation material for each language
>> reside in a single repository.
>> Comments would be appreciated.
>> If all is fine, I'll put this, with more details, to live.gnome.org.
>>
>> When splitting the l10n files from each module, there is a choice to either
>> 1. create a companion repository for each module (for example, for
>> mousetweaks, create 'mousetweaks-l10n')
>> that will hold all localisation files for all languages, for this module.
>> If we have 1000 modules, there would be 1000 additional companion l10n 
>> modules.
>> 2. create a repository for each language, and this repository will
>> contain all localisation files for all modules.
>> If we have 1000 modules, there would be just 160 additional l10n
>> repositories (it's one new repository per language).
>>
>> The right choice appears to be to create one repository per language.
>> There are many reasons which can be discussed if deemed necessary.
>>
>> The rest of the e-mail shows how the separated repositories look like.
>> I used as an example the mousetweaks and vinagre modules, for the el,
>> es, fr and sv languages.
>> Both have help/ and po/ subdirectories with l10n material.
>> You can fork the generated (six) repositories from
>> http://github.com/simos/ if you want to try them out.
>>
>> STRUCTURE (l10n-LL)
>> A language repository name is of the form 'l10n-LL', where LL is the
>> ISO 639 (-123) language code as usual.
>> Inside 'l10n-LL' there are directories per module (with the module
>> name), and further subdirectories 'po/' and 'help/' as necessary.
>> For example,
>>
>> l10n-el
>&g

Re: Using Git and separating translations into their own l10n-LL repository

[Simos Xenitellis]

On Wed, Jan 14, 2009 at 3:34 PM, Gil Forcada  wrote:
> El dc 14 de 01 de 2009 a les 00:42 +, en/na Simos Xenitellis va
> escriure:
>> On Tue, Jan 13, 2009 at 11:31 PM, Gil Forcada  wrote:
>> > Hi Simos,
>> >
>> > Great explanation, a couple of questions:
>> >
>> > - There would be any way to have in a single folder the code and
>> > translations (aka, the way is right now)? There are some translators
>> > (I'm counting in) that likes to have the code also.
>>
>> I am not sure which module you have in mind.
>
> Sorry, I wasn't really clear. I meant to keep like it is now with code
> and translations together.
>
>> I would say that the idea is, if the translation files are expected to
>> be managed by damned-lies/l10n.gnome.org, they should reside in the
>> l10n-LL submodule.
>>
>> > - The same concern about maintainers forgetting to git pull(?)
>> > translators is expanded, now they should git pull(?) every single git
>> > repository (if 160 languages, 160 git pulls(?) before each release).
>>
>> The 'git submodule update' command, when you run in from the 'l10n'
>> supermodule,
>> pulls all the l10n-LL repositories automatically by default.
>> There is an option to 'git submodule update' to pull individual
>> language repositories as well.
>
> If I understand correctly the repository will be like:
> l10n
> - l10n-LL
> -- evolution
> --- po
>  LL.po
> -- eog
> --- po
>  LL.po
> ...
>
> So if they update the whole l10n module (the top module) they will get
> all translations from all modules not all translations from their
> module.

Indeed, that is an issue. I did not find an easy way so that the
'l10n' tree can stay outside the repositories,
and each module would have a symbolic link towards 'l10n'.
That is,

 mousetweaks
 ├─ l10n (link to ../l10n)
 │...

In addition to this, there is the issue with branching; all modules in
a GNOME release
should branch at the same time, and have a standard common branch name.

Cheers,
Simos

>
>> > Also, if the new DL will have commit functionality (maybe in half a
>> > year, Claude ... :) and then *all* translations will be committed this
>> > way, wouldn't be overkill to have all this system?
>> >
>> > I mean, if it's a temporal situation that, shouldn't be more productive
>> > to instead of "wasting" time doing this git submodule thing to provide
>> > resources and time to get commit functionality to DL that seems to be
>> > more desired by translators (that's my guess no data actually, just
>> > supposed so my arguments seems better :D).
>>
>> I would consider that separating code from localisation files would be
>> a fundamental improvement rather than a temporary solution.
>> The issue of manpower to make such changes is the main disadvantage.
>>
>> It would be easier to provide commit support to damned-lies when
>> we have separated l10n-LL repositories. Damned-lies would 'auto'-commit
>> only to designated repositories.
>>
>> I do not know the details of the SVN hooks and damned-lies. I think
>> that if a commit/push to a project would call a hook that would invoke
>> 'intltool-update -P' (create POT template file) and store it
>> somewhere, then damned-lies would not need to clone locally any other
>> GNOME modules.
>>
>> To add a few more advantages,
>> 1. Can add access controls for translators to the l10n-LL repositories.
>> 2. It allows translators to make changes across all translations (for
>> example, change 'widget' in all my translations of GNOME).
>> 3. Pootle could be adapted to perform easier GNOME translation marathons.
>> 4. GTranslator could work as KBabel, it would clone the l10n-LL
>> repository and would be able to show all translations in a huge sorted
>> list. This way, similar translations can be easily identified.
>>
>> >
>> > El dt 13 de 01 de 2009 a les 23:01 +, en/na Simos Xenitellis va
>> > escriure:
>> >> Hi All,
>> >>
>> >> This is a long-ish post regarding the migration to Git and
>> >> what we can do to make l10n a bit better.
>> >>
>> >> Here I suggest to use the 'git submodule' support
>> >> so that the translation material for each language
>> >> reside in a single repository.
>> >> Comments would be appreciated.
>> >> If all is fine, I'll put this, with more details, to live.gnome.o

Re: Using Git and separating translations into their own l10n-LL repository

[Simos Xenitellis]

On Sat, Jan 17, 2009 at 6:39 PM, Kenneth Nielsen  wrote:
> 2009/1/16 Gil Forcada :
>>
>> El dv 16 de 01 de 2009 a les 01:42 +0100, en/na Christian Rose va
>> escriure:
>>> On 1/15/09, Claude Paroz  wrote:
>>> > Le mardi 13 janvier 2009 à 23:01 +, Simos Xenitellis a écrit :
>>> >  > This is a long-ish post regarding the migration to Git and
>>> >  > what we can do to make l10n a bit better.
>>> >  >
>>> >  > Here I suggest to use the 'git submodule' support
>>> >  > so that the translation material for each language
>>> >  > reside in a single repository.
>>> >  > Comments would be appreciated.
>>> >  > If all is fine, I'll put this, with more details, to live.gnome.org.
>>> >
>>> > 
>>> >
>>> >  Thanks Simos for taking the time to evaluate such an infrastructure for
>>> >  l10n.
>>> >  However I doubt the relative complexity implied by your solution is
>>> >  worth the trouble. I see basically two use cases:
>>> >
>>> >  1. The non-technical coordinator, who would like the simplest
>>> >  infrastructure to commit his translation files.
>>> >
>>> >  -> In this case, an auto-commit feature integrated in damned-lies is the
>>> >  best solution. No (D)VCS knowledge is required for him. FYI I've already
>>> >  tested a prototype which can do this in the testbed git infrastructure.
>>> >
>>> >
>>> >  2. The geek coordinator who like to have the most control on what he's
>>> >  doing and how he do it.
>>> >
>>> >  -> IMHO, this one won't mind checking out entire git modules. This is
>>> >  not very much different than the current situation.
>>>
>>> FWIW, I fully agree with Claude here.
>>
>> +1 also :)
>
> And a +1 from me.

OK, let's summarize for future reference and close the thread.

One of the issues to try to split translation files from the rest of
the modules is because a 'git clone' downloads the full history of a
repository, compared to a 'svn checkout' which downloads just a
snapshot. In addition, svn can also checkout a subdirectory of a
repository, something that git cannot do.

Separating the repositories in code and translations using 'git
submodule' would add too much effort in terms of updating the tools,
and changing the practices that translators would use to maintain the
translations. It is easier to keep as is.

In terms of disk space, a 'git clone' is surprisingly very economic,
almost matching an 'svn checkout'.
In terms of speed when cloning a repository, git is more CPU intensive
for the GIT server, and is slower than a 'svn checkout'.
It would make sense for translators to dedicate some space so that
cloned repositories are kept locally (instead of erasing them).

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Using Git and separating translations into their own l10n-LL repository

[Simos Xenitellis]

On Sun, Jan 18, 2009 at 9:55 AM, Gil Forcada  wrote:
> There isn't an option (I have read it somewhere, sorry for bad
> references) that tells git to only download the last version and not the
> full history?

There is an option '--depth 1' that you can use when you clone a repository.
Depending on the module, I noticed it gives up to moderate time and
space improvements.
git.gnome.org is now down, so I tried with
git://anongit.freedesktop.org/git/xorg/xserver

Clone: 1.43 min, objects 26.19 MiB, directory size 55MB
Shallow clone: 50s, objects 16.22 MiB, directory size 43MB

I also tried with the Linux kernel,
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

Clone: 9.10min, objects 258.23 MiB, directory size 660MB
Shallow clone: 5.38min, objects 152.34 MiB, directory size 531MB

When cloning, the 'Receiving objects' stage is the one that takes most
of the time
and refers to compressed data. I suppose it is a good indication of
the total time.

When I tried the other day with git.gnome.org, I noticed much slower times.
It appears the reason is that git.gnome.org (test server) was very
slow when I tried it,
achieving up to 100KB/s at best. With X.Org and the Linux kernel, the
speed was most of the time at 800KB/s.

In addition, the 'git clone' man page mentions

"--depth 

Create a shallow clone with a history truncated to the specified
number of revisions. A shallow repository has a number of limitations
(you cannot clone or fetch from it, nor push from nor into it), but is
adequate if you are only interested in the recent history of a large
project with a long history, and would want to send in fixes as
patches."

It says that you cannot "push from [a shallow clone]", which means
that a translator would not be able to push a translation from a
shallow clone. I tried with a small repository where I have push
access and I was able to push a commit from a shallow clone to the git
server. This may be some feature on GitHub; all Google searches for
'shallow clone' repeat that you cannot push your changes from your
shallow clone.
It would be important to try this one out on git.gnome.org, when it is
available.

Simos

> Cheers,
>
> El dg 18 de 01 de 2009 a les 00:01 +, en/na Simos Xenitellis va
> escriure:
>> On Sat, Jan 17, 2009 at 6:39 PM, Kenneth Nielsen  
>> wrote:
>> > 2009/1/16 Gil Forcada :
>> >>
>> >> El dv 16 de 01 de 2009 a les 01:42 +0100, en/na Christian Rose va
>> >> escriure:
>> >>> On 1/15/09, Claude Paroz  wrote:
>> >>> > Le mardi 13 janvier 2009 à 23:01 +, Simos Xenitellis a écrit :
>> >>> >  > This is a long-ish post regarding the migration to Git and
>> >>> >  > what we can do to make l10n a bit better.
>> >>> >  >
>> >>> >  > Here I suggest to use the 'git submodule' support
>> >>> >  > so that the translation material for each language
>> >>> >  > reside in a single repository.
>> >>> >  > Comments would be appreciated.
>> >>> >  > If all is fine, I'll put this, with more details, to live.gnome.org.
>> >>> >
>> >>> > 
>> >>> >
>> >>> >  Thanks Simos for taking the time to evaluate such an infrastructure 
>> >>> > for
>> >>> >  l10n.
>> >>> >  However I doubt the relative complexity implied by your solution is
>> >>> >  worth the trouble. I see basically two use cases:
>> >>> >
>> >>> >  1. The non-technical coordinator, who would like the simplest
>> >>> >  infrastructure to commit his translation files.
>> >>> >
>> >>> >  -> In this case, an auto-commit feature integrated in damned-lies is 
>> >>> > the
>> >>> >  best solution. No (D)VCS knowledge is required for him. FYI I've 
>> >>> > already
>> >>> >  tested a prototype which can do this in the testbed git 
>> >>> > infrastructure.
>> >>> >
>> >>> >
>> >>> >  2. The geek coordinator who like to have the most control on what he's
>> >>> >  doing and how he do it.
>> >>> >
>> >>> >  -> IMHO, this one won't mind checking out entire git modules. This is
>> >>> >  not very much different than the current situation.
>> >>>
>> >>> FWIW, I fully agree with Claude here.
>> >>
>> >> +1 also :)
>> >
>> > And a +1 from me.
>&g

Re: Using Git and separating translations into their own l10n-LL repository

[Simos Xenitellis]

On Mon, Jan 19, 2009 at 12:57 PM, Matej Urban  wrote:
> Thanks, Gil,
>
> I will wait and see, but since I'm a translator/mantainer and since I
> doubt I will be able to upload many files at once, the only difference
> so far I see, is that I will replace keyboard keystrokes for mouse
> clicks. There will be no changelog, which is an improvement :)
>
> Anyhow, in the end I will use whatever I'll need to do it, but keep
> nagging about it. For some reason, I really doubt that single dir for
> all po files, is a big programing deal. No obsolete clicks, no hassle,
> just pure translation work.

For the part where you would want to upload several PO files in one
go, it should be feasible to adapt damned-lies (as soon as single PO
file uploads are enabled) to upload .tar.gz archives of several PO
files.

I created a bug report about this at
"Allow to also commit archives of PO files (instead of single PO files)"
http://bugzilla.gnome.org/show_bug.cgi?id=568295

Simos

>
> On Mon, Jan 19, 2009 at 1:46 PM, Gil Forcada  wrote:
>> Hi,
>>
>> Actually a lot has changed:
>>
>> - for advanced-translators the same workflow will be maintained.
>> - for plain translators a web interface to commit languages will be
>> provided.
>>
>> So I think you fall in the second option and thus you will need to have
>> access to http://l10n.gnome.org to download updated po files (like you
>> can do right know), track its status (like as of January you can do
>> right now) and commit them in source repositories (like you will be able
>> to do in a not-so-distant-future, Claude said it has a beta working
>> version that does this, I'm right Claude?)
>>
>> So, all in all, your workflow will be a lot improved since you will only
>> have to download and upload files from/to http://l10n.gnome.org :)
>>
>> Hope I haven't said any lie!
>>
>> Cheers,
>>
>> El dl 19 de 01 de 2009 a les 13:38 +0100, en/na Matej Urban va escriure:
>>> Hello,
>>>
>>> I'm really trying to understand the changes. The title sais:
>>> Using Git and separating translations into their own l10n-LL repository
>>>
>>> The title implies that ALL and ONLY po files from ALL the languages UI
>>> and HELP will fall into "l10n-LL" repository, but that will not be the
>>> case, as I understand. I really don't know why this is so unpopular
>>> among developers.
>>>
>>> I posted a bug http://bugzilla.gnome.org/show_bug.cgi?id=554257 and
>>> also a reminder that I don't fill-in the changelog entries. I can not
>>> find those great "scripts" in the gnome archive, that will do all the
>>> work in my place, nor can I write one, so doing it step by step is the
>>> only way I know. It takes TOO much time, TOO much bandwidth and TOO
>>> much space to maintain the language. Putting/linking/sync all po files
>>> in one single dir solves many problems for coords like myself.
>>>
>>> Please, guys, check again if there is a way to do that. Last
>>> coordinator dropped out of the translation game because this updating
>>> took too much of everything, especially his time.
>>>
>>> Matej
>> --
>> gil forcada
>>
>> [ca] guifi.net - una xarxa lliure que no para de créixer
>> [en] guifi.net - a non-stopping free network
>> bloc: http://gil.badall.net
>>
>>
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Trying out Git (for translators)

[Simos Xenitellis]

Hi All,

There are some instructions at
http://live.gnome.org/GitMigration/Translators
that describe the commands to use Git.

The server git.gnome.org is available for testing (it contains test
copies of repositories),
and any changes you make will be eventually discarded when the final
migration takes place.

I think it would be a good opportunity to try out the commands
and upload some (dummy) translation updates.

If you use Debian/Ubuntu, you need to install the 'git-core' package
in order to get the Git commands.

Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Trying out Git (for translators)

[Simos Xenitellis]

On Mon, Jan 19, 2009 at 7:20 PM, Shaun McCance  wrote:
> On Mon, 2009-01-19 at 13:40 +0000, Simos Xenitellis wrote:
>> Hi All,
>>
>> There are some instructions at
>> http://live.gnome.org/GitMigration/Translators
>> that describe the commands to use Git.
>>
>> The server git.gnome.org is available for testing (it contains test
>> copies of repositories),
>> and any changes you make will be eventually discarded when the final
>> migration takes place.
>>
>> I think it would be a good opportunity to try out the commands
>> and upload some (dummy) translation updates.
>>
>> If you use Debian/Ubuntu, you need to install the 'git-core' package
>> in order to get the Git commands.
>
> Hi Simos,
>
> This is really nice.  I'd like to offer one tip that people might
> find useful.  The "git commit" command can optionally take file
> names to commit.  These are effectively auto-added before commit.
>
> I don't use "commit -a", because I like to review my work, but
> when you just want to commit a single file, as translators would,
> "git commit el.po" is easier than "git add el.po; git commit".
>
> Nothing Earth-shattering.  Just thought it would be handy to our
> intrepid translators.

Hi Shaun,

In usability terms, it's a big improvement to eliminate a step.
I am updating the wiki page.

Cheers,
Simos
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Trying out Git (for translators)

[Simos Xenitellis]

Hello Ihar,

My understanding is that the consensus is towards git.
I did not notice an announcement that picks officially git in the place
of other distributed SCMs. However, since many people are working now
on testing git,
I assume that this is the direction.

I hope this helps,
Simos

On Mon, Jan 19, 2009 at 7:54 PM, Ihar Hrachyshka
 wrote:
> Maybe I missed something. Is it 100% that Git will be used for Gnome
> development?
>
> On Mon, Jan 19, 2009 at 3:40 PM, Simos Xenitellis
>  wrote:
>> Hi All,
>>
>> There are some instructions at
>> http://live.gnome.org/GitMigration/Translators
>> that describe the commands to use Git.
>>
>> The server git.gnome.org is available for testing (it contains test
>> copies of repositories),
>> and any changes you make will be eventually discarded when the final
>> migration takes place.
>>
>> I think it would be a good opportunity to try out the commands
>> and upload some (dummy) translation updates.
>>
>> If you use Debian/Ubuntu, you need to install the 'git-core' package
>> in order to get the Git commands.
>>
>> Simos
>> ___
>> gnome-i18n mailing list
>> gnome-i18n@gnome.org
>> http://mail.gnome.org/mailman/listinfo/gnome-i18n
>>
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Using Git and separating translations into their own l10n-LL repository

[Simos Xenitellis]

On Wed, Jan 21, 2009 at 8:27 AM, Matej Urban  wrote:
> Well, I'm sure the devels are able to make the system work in anyway
> they choose, that's why I yell so loudly to get all the po files of
> one language into one single directory. Now that would cut down the
> maintenance.
>
> If you take a look the translation process, you see, that it consists
> of 3 major steps. Acquiring the file(s) to translate, translating and
> commiting.
>
> When you "choose" the file, you have to know what is already
> translated, what is reserved, proofed ... or under revision. You also
> have to have a quick access to pot files. How many clicks you need to
> do that? If it's more than one after visiting the page from your
> favorite bar, there is something like click/bandwidth/time, that can
> be improved, right?
>
> Translation by itself is an individual project and has nothing to do
> with the git or svn.
>
> How many times did you "correct" a single word, that was not syncd in
> many translations? Last time I did that I had to "repair" 17 files.
> Why carry apple by apple from the market if you can take a basket with
> you. If you need more than one line in svn/git or one click on the
> website more than it's necessary, there is space for improvement,
> rignt. Getting the files up and down should mean NO effort. It should
> be easier then ftp-ing them to some server. The real work, with all
> the logging and diffing, crediting, upgrading and stuff should start
> from that point on.
>
> The last maintainer quit being a mantainer, because he had no time.
> The last zip that I sent him for 2.22 some time ago had 83 upgraded
> files. If someone sends me 83 files to commit, I'd break down and cry
> ...
>
> Then I'd start again yelling about SINGLE FOLDER for one language.
> Less time needed, less bandwidth, less clicks, less nerves, more
> translating and proofing. A winning situation.

Hi Matej,
Earlier in this thread I mention a possible way to have all
translations for each language in its own repository (thus, single
folder). There where some advantages and disadvantages with this
process. I am not sure if you managed to try it using the test
repositories from github.com.
I believe there is a potential to adapt the proposal so that the
disadvantages are eliminated.
If you want to have a look at it, it would be great. I'ld be happy to
discuss about it.

An alternative to the initial proposal of this thread would be to get
damned-lies to allow to commit many translation files, as described in
the other thread. The bug report is
http://bugzilla.gnome.org/show_bug.cgi?id=568295

Simos

> On Tue, Jan 20, 2009 at 4:55 PM, Kenneth Nielsen  
> wrote:
>> 2009/1/19 Matej Urban :
>>> Thanks, Gil,
>>>
>>> I will wait and see, but since I'm a translator/mantainer and since I
>>> doubt I will be able to upload many files at once, the only difference
>>> so far I see, is that I will replace keyboard keystrokes for mouse
>>> clicks. There will be no changelog, which is an improvement :)
>>
>> I don't see how this solution will NOT improve your situation. When
>> you want to commit you just have to upload a file via a web-interface.
>> Which means that you cut both space and bandwitdth down to a minimum,
>> the only thing left is time. You do save the time it takes out to
>> check out the modules and fill out the ChangeLog, but you do not get
>> to save the time you could if you could commit more files at once. But
>> in my opinion that should never be made a possibility (and I'm a
>> translation coordinator not a developer), you use verision control
>> systems (of any kind) to track changes, which makes it easy to revert
>> if you do something wrong, but that hardly makes sense if you commit
>> very large changes.
>>
>> Regards Kenneth
>>
>> PS: I have a commit script I can send you if you want to use it in the
>> meantime, but let me know only if you want to use it as I would have
>> to nicefy it a bit before ot could be used by others.
>>
>>>
>>> Anyhow, in the end I will use whatever I'll need to do it, but keep
>>> nagging about it. For some reason, I really doubt that single dir for
>>> all po files, is a big programing deal. No obsolete clicks, no hassle,
>>> just pure translation work.
>>>
>>> Matej
>>>
>>> On Mon, Jan 19, 2009 at 1:46 PM, Gil Forcada  wrote:
 Hi,

 Actually a lot has changed:

 - for advanced-translators the same workflow will be maintained.
 - for plain translators a web interface to commit languages will be
 provided.

 So I think you fall in the second option and thus you will need to have
 access to http://l10n.gnome.org to download updated po files (like you
 can do right know), track its status (like as of January you can do
 right now) and commit them in source repositories (like you will be able
 to do in a not-so-distant-future, Claude said it has a beta working
 version that does this, I'm right Claude?)

 So, all in all, your workflow will

Re: Using Git and separating translations into their own l10n-LL repository

[Simos Xenitellis]

On Thu, Jan 22, 2009 at 9:18 AM, Kenneth Nielsen  wrote:
> Hey Matej
>
> 2009/1/22 Matej Urban :
>>> Damned lies alrayde have the options download everything from a
>>> release set. Look all the way at the bottom of this page:
>>> http://l10n.gnome.org/languages/da/gnome-2-26/ui/
>>
>> Can I download all the pot files? I'm not aware of it.
>
> What do you need pot-files for? You will get updated po-files which is
> what you need if there already os a translation or a pot-files if
> there wasn't already one. And yes you can, just press the button that
> says "Download all po files" at the bottom of the page I just sent you
> a link for and you will get a tar-ball with all the Danish
> po/pot-files. I'm sure you can extrapolate that for you own language.
>
>>
 How many times did you "correct" a single word, that was not syncd in
 many translations?
>>>
>>> Never, because we have a wordlist which we use pretty consistently
>>
>> That is something we still have to do. But "pretty consistently" tells
>> me, that it happens, right.
>>
>>> Why? It is a task, and as such will require work.
>>
>> Agreed! But work on translations, not with committing.
>
> That is part of the task.
>
>>> In any case, you have already been told that it is certainly possilble to 
>>> add the
>>> option to upload several files at once in Damned Lies, in that case
>>> you both have the options to get all files easily and you can have the
>>> possibility to commit several files in  Damned Lies. The isn't that
>>> enough, isn't that exactly what you want, so that we can leave the
>>> repositories on their own and in a structure that makes sense i.e. one
>>> module-wise.
>>
>> It would be an improvement, but one folder system would be much
>> better.
>
> Why? If you can commit a tar-ball to Damned Lies with several files in
> it in one go (one clicky-di-click) and then they will all be commited
> at once, then isn't that exactly the functionality you are asking for?

The functionality of being able to submit a single file through the
web interface from Damned-lies and make it to GNOME SVN/GIT is not
available yet. The ability to submit several files would be an
addition to the previous task, and is not available yet either.

>>  I believe, that It should not be a big deal keeping the
>> structure intact and syncing the whole lot with single folder. Maybe
>> I'm wrong.
>
> From what I could read from the previous e-mails about how to use git
> with submodules, to link translations in form their own module, it
> will be significantly more complex.

'git submodule' is a functionality that was introduced to git quite recently,
and the process I described at the start of this thread was indeed
complex and most importantly error-prone. So the decision later on in
this thread was not to use 'git submodule', in the way described at
the start of the thread.

Simos

> Regards Kenneth Nielsen
>
>>> Yeah, but perhaps you could have sent him something a little before it
>>> reached 83 !?!
>>
>> I agree, but at that time I was sure, that he only "ftps" them to
>> repos and thought, I only did him a favour when sending all at once,
>> not giving him too much work ...
>> Funny right :)
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Ανοιχτή συζήτηση περί των έρ γων μετάφρασης από την εταιρία Ε ΕΛΛΑΚ

[Simos Xenitellis]

Να υπενθυμίσω ότι αν θέλετε να ρωτήσετε κάτι σχετικά με το διαγωνισμό
«Πρόσκληση εκδήλωσης ενδιαφέροντος για την Ελληνοποίηση ΕΛΛΑΚ Λογισμικών
που είναι χρήσιμα για επιχειρήσεις και την εκπαιδευτική κοινότητα»
http://www.ellak.gr/index.php?option=com_openwiki&Itemid=103&id=eellak:metafraseis

θα είμαι διαθέσιμος σήμερα το βράδυ (10μμ) στο IRC, Δίκτυο Freenode,
κανάλι #gnome-el.
http://wiki.ubuntu-gr.org/Wiki/Community/IRC

Σίμος
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n