harfbuzz-0.9.2 now available

[Behdad Esfahbod]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi everyone,

So, after (finally!) implementing synthetic GDEF and fallback mark
positioning, I found myself running out of major features to implement this
week.  I can finally claim that new HarfBuzz is in par with or better than
both Pango and old.HarfBuzz / Qt.  The main outstanding issue that I know of
is Indic support with Free fonts, which I hope to improve in the coming weeks.
 Testing and reports will be key to what I will end up working on.

With features complete, and performance looking good, I'm shifting gears to
release mode, starting with a 0.9.2 release today, and working my way towards
a 1.0 release around the end of the month or in early September.  This may be
a good time for distributions to start putting a harfbuzz package together.  A
proper build system will be coming soon.

I put a short checklist together to track 1.0 progress:

  http://goo.gl/4xnyw

Feel free to comment (on the doc or on the list).

In the mean time, enjoy the 0.9.2 release!

  http://www.freedesktop.org/software/harfbuzz/release/

As always, I like to specially thank Jonathan Kew, as well as everyone who
helped with testing.

Cheers,
Behdad Esfahbod
August 10, 2012


Overview of changes leading to 0.9.2
Friday, Aug 10, 2011


- - Over a thousand commits!  This is the first major release of HarfBuzz.

- - HarfBuzz is feature-complete now!  It should be in par, or better, than
  both Pango's shapers and old HarfBuzz / Qt shapers.

- - New Indic shaper, supporting main Indic scripts, Sinhala, and Khmer.

- - Improved Arabic shaper, with fallback Arabic shaping, supporting Arabic,
  Sinhala, N'ko, Mongolian, and Mandaic.

- - New Thai / Lao shaper.

- - Tibetan / Hangul support in the generic shaper.

- - Synthetic GDEF support for fonts without a GDEF table.

- - Fallback mark positioning for fonts without a GPOS table.

- - Unicode normalization shaping heuristic during glyph mapping.

- - New experimental Graphite2 backend.

- - New Uniscribe backend (primarily for testing).

- - New CoreText backend (primarily for testing).

- - Major optimization and speedup.

- - Test suites and testing infrastructure (work in progress).

- - Greatly improved hb-view cmdline tool.

- - hb-shape cmdline tool.

- - Unicode 6.1 support.

Summary of API changes:

o Changed API:

  - Users are expected to only include main header files now (ie. hb.h,
hb-glib.h, hb-ft.h, ...)

  - All struct tag names had their initial underscore removed.
Ie. "struct _hb_buffer_t" is "struct hb_buffer_t" now.

  - All set_user_data() functions now take a "replace" boolean parameter.

  - hb_buffer_create() takes zero arguments now.
Use hb_buffer_pre_allocate() to pre-allocate.

  - hb_buffer_add_utf*() now accept -1 for length parameteres,
meaning "nul-terminated".

  - hb_direction_t enum values changed.

  - All *_from_string() APIs now take a length parameter to allow for
non-nul-terminated strings. A -1 length means "nul-terminated".

  - Typedef for hb_language_t changed.

  - hb_get_table_func_t renamed to hb_reference_table_func_t.

  - hb_ot_layout_table_choose_script()

  - Various renames in hb-unicode.h.

o New API:

  - hb_buffer_guess_properties()
Automatically called by hb_shape().

  - hb_buffer_normalize_glyphs()

  - hb_tag_from_string()

  - hb-coretext.h

  - hb-uniscribe.h

  - hb_face_reference_blob()
  - hb_face_[sg]et_index()
  - hb_face_set_upem()

  - hb_font_get_glyph_name_func_t
hb_font_get_glyph_from_name_func_t
hb_font_funcs_set_glyph_name_func()
hb_font_funcs_set_glyph_from_name_func()
hb_font_get_glyph_name()
hb_font_get_glyph_from_name()
hb_font_glyph_to_string()
hb_font_glyph_from_string()

  - hb_font_set_funcs_data()

  - hb_ft_font_set_funcs()
  - hb_ft_font_get_face()

  - hb-gobject.h (work in progress)

  - hb_ot_shape_glyphs_closure()
hb_ot_layout_substitute_closure_lookup()

  - hb-set.h

  - hb_shape_full()

  - hb_unicode_combining_class_t

  - hb_unicode_compose_func_t
hb_unicode_decompose_func_t
hb_unicode_decompose_compatibility_func_t
hb_unicode_funcs_set_compose_func()
hb_unicode_funcs_set_decompose_func()
hb_unicode_funcs_set_decompose_compatibility_func()
hb_unicode_compose()
hb_unicode_decompose()
hb_unicode_decompose_compatibility()

o Removed API:

  - hb_ft_get_font_funcs()

  - hb_ot_layout_substitute_start()
hb_ot_layout_substitute_lookup()
hb_ot_layout_substitute_finish()
hb_ot_layout_position_start()
hb_ot_layout_position_lookup()
hb_ot_layout_position_finish()

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAlW/YACgkQn+4E5dNTERXQPwCePZGJN/mV/eNcgg0+SfOq2kFQ
0nQAoLYybPR6aSSsISywdHgFstxGm0w8
=8/5G
-END PGP SIGNATURE-
_

vte branched for gnome-2-30

[Behdad Esfahbod]

Please update.

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

[vte] Created branch gnome-2-30

[Behdad Esfahbod]

The branch 'gnome-2-30' was created pointing to:

 953625f... [git.mk] Update from pango

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

Re: String additions to 'gnome-terminal.master'

[Behdad Esfahbod]

On 03/17/2010 09:41 AM, Behdad Esfahbod wrote:
> 
> Heya,
> 
> Sorry, didn't mean to break.  gnome-terminal 2.30.0 was released on Monday.

I was wrong.  It wasn't released.

> We'll fork from before this change.

I created a gnome-2-30 branch now and cherry-picked all the recent translation
updates into it.  Please update.

behdad

> behdad
> 
> 
>> Thanks! (Also for the useful new feature... :))
>>
>> — Wouter
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

[gnome-terminal] (5 commits) Created branch gnome-2-30

[Behdad Esfahbod]

The branch 'gnome-2-30' was created.

Summary of new commits:

  1000bca... Updated Slovenian translation
  fd6249b... Dutch translation updated by Wouter Bolsterlee
  c8adcfc... Updated Spanish translation
  d6b5974... Updated Basque language
  f6471f6... Update Russian translation by Alexander Saprykin
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: String additions to 'gnome-terminal.master'

[Behdad Esfahbod]

On 03/16/2010 06:53 PM, Wouter Bolsterlee wrote:
> Op dinsdag 16-03-2010 om 20:09 uur [tijdzone +], schreef GNOME
> Status Pages:
>> This is an automatic notification from status generation scripts on:
>> http://l10n.gnome.org.
>>
>> There have been following string additions to module 'gnome-terminal.master':
>>
>> + "If true, newly created terminal windows will have custom size specified 
>> by default_size_columns and default_size_rows."
>> + "Number of columns in newly created terminal windows. Has no effect if 
>> use_custom_default_size is not enabled."
>> + "Number of rows in newly created terminal windows. Has no effect if 
>> use_custom_default_size is not enabled."
>> + "Use custom default terminal si_ze"
>> + "Whether to use custom terminal size for new windows"
> 
> Hi Behdad,
> 
> It seems you broke string freeze with this commit:
> http://git.gnome.org/browse/gnome-terminal/commit/?id=0f0fafbe950e5c57b3345524602a226b597a319f
> 
> I cannot find any string freeze break request, so please revert or ask
> for approval first.

Heya,

Sorry, didn't mean to break.  gnome-terminal 2.30.0 was released on Monday.
We'll fork from before this change.

behdad


> Thanks! (Also for the useful new feature... :))
> 
> — Wouter
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: vte branched

[Behdad Esfahbod]

On 10/27/2009 02:29 PM, Johannes Schmid wrote:

Hi!

Am Dienstag, den 27.10.2009, 14:18 -0400 schrieb Behdad Esfahbod:

I created the vte-0-22 branch for stable releases.


Just out of interest: Is there a good reason for vte not to follow the
GNOME version/branching schema?


Umm, no reason other than historical reasons :">.
I see another one now though:  I expect to break vte's release cycle from 
GNOME for one or two cycles starting now.


behdad



Thanks,
Johannes

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

vte branched

[Behdad Esfahbod]

I created the vte-0-22 branch for stable releases.

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

Re: Fwd: Pango Crashes with the error : Pango:ERROR:/build/buildd/pango1.0-1.24.1/pango/pango-layout.c:3748:pango_layout_check_lines: assertion failed: (!layout->log_attrs)

[Behdad Esfahbod]

On 08/24/2009 04:26 AM, Valentino wrote:

hi all,
i am implementing entry widget of my own on Xlib with pango and cairo. i
finished most of the thing . but it crashes sometimes if i enter
characters continuously with the error
pango_layout_check_lines: assertion failed:
(!layout->log_attrs)please help!


It's impossible to say much without more information.  My only guess is that 
you are using the same layout from multiple threads.  If that's the case, 
don't do that.


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

Re: Question about git

[Behdad Esfahbod]

On 05/06/2009 07:00 AM, Simos Xenitellis wrote:

On Tue, May 5, 2009 at 4:41 PM, Behdad Esfahbod  wrote:

On 05/05/2009 01:28 AM, Shaun McCance wrote:


This assumes that the branch is merged into master otherwise.  I strongly
suggest cherry-pick instead of merge.

Isn't that going to cause merge conflicts for me the
maintainer when I try to merge from my stable branches
to master?  I can pretty much guarantee I will always
do that.  If I have to deal with merge conflicts from
one of 100 translations each time, I'm not going to
be happy.

I *think* if the same commit exists in the destination, it doesn't cause a
merge conflict.  But I didn't test it to make sure right now.


I have tried a few scenarios with 'git merge' and I managed to get a
situation that merge could not take place.
After that, it was not possible to commit and the message was too
cryptic to figure out what to do.
In terms of usability for this process, it was good (I was blocked
from messing up further),
so I resorted to the HowTo item from live.gnome.org named 'Ok, I
messed up, what do I do' in order to reset my clone.

As a workflow, I find that the following is easy to follow
1. First commit to your branch (such as gnome-2-26) as normal.
2. Then, checkout 'master' and 'git merge gnome-2-26'
3. Observe that no errors appear and that only your changes are merged.
4. Do a 'git push' to push your work to git.gnome.org.


What if the branch was not merged, perhaps intentionally?  Now the translator 
will be pushing code changes.



I am OK to add a section in the HowTO for 'git cherry-pick'. I find however
the process more error prone due to the fact that one needs to figure
out the hash
of the last commit(s) in the branch and use that for cherry-picking.


If it's indeed the last commit, they can cherry pick the branch tip by just 
cherry-pick'ing the branch.  Right?


behdad


Simos


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

Re: Question about git

[Behdad Esfahbod]

On 05/05/2009 01:28 AM, Shaun McCance wrote:


This assumes that the branch is merged into master otherwise.  I strongly
suggest cherry-pick instead of merge.


Isn't that going to cause merge conflicts for me the
maintainer when I try to merge from my stable branches
to master?  I can pretty much guarantee I will always
do that.  If I have to deal with merge conflicts from
one of 100 translations each time, I'm not going to
be happy.


I *think* if the same commit exists in the destination, it doesn't cause a 
merge conflict.  But I didn't test it to make sure right now.


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

Re: Question about git

[Behdad Esfahbod]

On 05/04/2009 07:07 PM, Simos Xenitellis wrote:

On Mon, May 4, 2009 at 11:10 PM, Gil Forcada  wrote:

El dl 04 de 05 de 2009 a les 23:00 +0200, en/na Milo Casagrande va
escriure:

Hi,

here I come again with silly question about git. :)

I did look at the documentation, but didn't find an answer so maybe some
more involved git user could tell me if it's possible or not.

Is it possible to merge a single file from two different branches?

Say I commit a translation in gnome-2-26 and I want to port the same
translation to master, do I have to do it "manually" (as I'm doing it
now)?

By "manually" I intend: switch to the other branch and re-copy again the
same po file.

/me wants to know this also, anyone?


There was a discussion on this recently on gnome-infrastructure,
http://mail.gnome.org/archives/gnome-infrastructure/2009-April/thread.html#00178

One (slightly difficult) way is to use 'git cherry-pick', as described at
http://mail.gnome.org/archives/gnome-infrastructure/2009-April/msg00179.html

There are two ways to do this. The easiest is what Shaun describes at
http://mail.gnome.org/archives/gnome-infrastructure/2009-April/msg00194.html

1. First make the change in the branch (such as gnome-2-26) and commit it.

2. Then, move back to 'master', which is done with
$ git checkout master
Switched to branch "master"
$ _

3. Finally, merge the commit from the branch onto the master
$ git merge gnome-2-26
Updating 2cb6a91..6a17d40
Fast forward
  po/el.po |2 --
  1 files changed, 0 insertions(+), 2 deletions(-)
$ _

The job is done, you can now push so that both the branch and 'master'
get to git.gnome.org ;-).


This assumes that the branch is merged into master otherwise.  I strongly 
suggest cherry-pick instead of merge.


behdad


Simos

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

Re: Issue with Merge Commits and using 'git pull --rebase' (Was: Re: Trying to understand git)

[Behdad Esfahbod]

On 04/20/2009 05:45 PM, Simos Xenitellis wrote:

2009/4/20 Milo Casagrande:

Hi,

I'm here again with silly questions trying to understand the correct use
of git...

Today I did a commit for pitivi [1], I was in master (and my copy is
still in master) and I did the commit there, when I checked at cgit the
green box with master written on it was on my commit description.

Tonight I'm told by our Italian coordinator that probably I've done
something wrong, because looks like the same commit I did has been
redone [2].

What did I do wrong?

I really don't understand... sorry...

[1]
http://git.gnome.org/cgit/pitivi/commit/?id=2dc963da049c0eb05ac2d4887ed88415fef181af
[2]
http://git.gnome.org/cgit/pitivi/commit/?id=2a7f5b319cb55c8851ab5141d55c42e5e5dca59f



Oh, you did a 'merge-commit'. I did one of those to 'gtk+', no less...
The technical description is at
http://live.gnome.org/Git/Help/ExtraMergeCommits
and apparently, now, git.gnome.org is supposed to detect those and
give you an error message.
It is not clear why your commit was not caught in your case.

The short solution is, instead of 'git pull', to do

$ git pull --rebase

You may also add an alias to Git:

$ git config --global alias.up "pull --rebase"


Or do:

git config --global branch.master.rebase true


behdad



which means that instead of 'git pull --rebase', you can now simply type

$ git up   ('up' is for update, since
there is no 'git-update' command)

These have been recently added to
http://live.gnome.org/TranslationProject/GitHowTo

- What does 'rebase' do?
- 'git up' or 'git pull --rebase' updates your local repository from
git.gnome.org. If you have a local commit
already applied, 'git up' or 'git pull --rebase' will transform
automatically for you your local repository
so that your commit will appear as it is the last commit to the
repository. So that you can 'git push' it
and have it put on top of the last commit, and maintain a nice linear tree.

TROUBLESHOOTING
Q. When I try 'git up' or 'git pull --rebase', I get the error
«Error: refusing to pull with rebase: your working tree is not up-to-date»
A. In order to rebase, you need to commit first your local changes

Hope this helps,
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: Moving GLib and GTK+ to git

[Behdad Esfahbod]

On 04/03/2009 03:04 AM, Edward Hervey wrote:

   FWIW, In GStreamer git repositories we use that same rule for the
one-liner with a subtle variation:
   * We do allow capital letters (seriously, who cares? It looks nice)
   * Considering you want to have as much info as possible in that
one-liner, we try to prefix it with a word giving a clue as to where the
work was done (without looking at the modified files). Doesn't apply if
it's a change accross the whole module.
   Ex :
"rtspsrc: allow http:// on the proxy setting", or
"Mark unused arguments using G_GNUC_UNUSED glib macro."


Right.  In cairo and pango we do the same, with a slightly different syntax. 
For example:


[win32] Fix horizontal glyph positioning bug
[test] Memfault checks
[surface] Propagate region allocation failure
[traps] Propagate allocation failure
[region] Use const cairo_rectangle_int_t consistently
[scaled-font] Global glyph cache

I find that quite useful.

behdad


  Edward

BR,
Martin

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

Re: Moving GLib and GTK+ to git

[Behdad Esfahbod]

On 03/31/2009 03:50 PM, David Zeuthen wrote:

Personally I prefer non-capital and no periods; it makes the output of
'git log |git shortlog' nicer to look at (see [1] for an example) but
maybe that's just me. I think capital letters would work nice here too;
trailing periods would probably look weird though.


While I prefer to capitalize sentence starters, NOT capitalizing makes it 
easier to start a commit summary with an API symbol name or other identifiers 
that should not be capitalized.


behdad


  David


[1] :

David Zeuthen (198):
   [...]
   add some notes about terminology
   use the term "Name" instead of "Label" when creating a partition
   rework terminology for filesystem labels / partition labels
   fix compiler warnings introduced by the last set of patches
   add some experimental code for grid-based layout
   fix some criticals where we tried to access non-existant widgets
   rework partition table handling

Matthias Clasen (13):
   HIG fixes
   trivial coding style fix
   avoid dialog resizing
   don't allow empty passphrases
   improved spacing for sections
   [...]


___
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: Moving GLib and GTK+ to git

[Behdad Esfahbod]

On 03/31/2009 03:05 PM, Matthias Clasen wrote:


Some things that we need to sort out include

ChangeLog: The git way of doing things is to do small commits, with
meaningful commit messages, and forego a separate ChangeLog file.
Everybody who I talked to about this recommended going this way, so
I'd say we should follow this. I'll add a final note to the current
ChangeLog indicating this.

I'll figure out what to do about autogenerating ChangeLogs in release
tarballs in time for the next releases...


Feel free to copy from Pango.  Pango only has one ChangeLog though.  You may 
want to consolidate gtk's many ones now.




The one deviation in this from our current ChangeLog entry style is
that it moves the bug reference from the short explanation to the main
description.
I'm not entirely sure which is better here, a little experimentation
may be needed to come up with the best style.


For Pango I continue to use the bug title line as my short summary.  If 
needed, I retitle the bug first.  For example:



commit cf13cde8a80c9a1a9d4c9e343c634350da59991a
Author: Behdad Esfahbod 
Date:   Thu Mar 26 01:03:43 2009 -0400

Bug 571291 – Unicode 5.1 support in pango - Indic Lanuages

Add char class for new characters.
Patch from Rahul Bhalerao.

commit 477747bc1ef1078b06c4e1c615a1a912e6ada299
Author: Sebastian Dröge 
Date:   Mon Mar 23 19:16:58 2009 -0400

Bug 576298 – Fails to link pango-view if --without-x is specified but 
cairo has X11 support


commit c82e8ad9dda142b1acfbcb86054750e082600893
Author: Behdad Esfahbod 
Date:   Mon Mar 16 17:25:33 2009 -0400

Bug 547963 – man page for pango-view

commit 69e1f7921525c2849d937b5a822475007a4f9a2f
Author: Behdad Esfahbod 
Date:   Mon Mar 16 16:57:58 2009 -0400

Bug 502804 – pango-view or pangocairo-view option to annotate

Added --annotate.

Also fixes:
Bug 502801 – per-backend pango-view options


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

Re: Don't add ChangeLog entries to ChangeLog-less modules

[Behdad Esfahbod]

On 03/15/2009 02:38 PM, Александър Шопов wrote:

There is good reason.  I don't see how it's relevant to whether you should
edit ChangeLog.preX.Y or not.  How is editing that wrong file making your job
easier?

Easier or not, if a module doesn't have ChangeLog, it doesn't.  If you don't
like that, file a bug against them.

It is just days before release, so I would suppose the discussion could
be postponed a little bit.
However after the release there would be quite a lot changes like new
source control system.
Could we discuss things then with more clarity then so that it would be
both easier for translators to know which files to or not to change and
not more difficult for developers. Doing things the same way (AKA
standards) could be helpful.

Still I would suppose that the bugtrack will not be the proper place for
reality complaints.

Will that be the infrastructure or the foundation list, Behdad?


Neither.  Either desktop-devel-list, or, as I said, bugzilla.

behdad


Kind regards:
al_shopov

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

Re: Don't add ChangeLog entries to ChangeLog-less modules

[Behdad Esfahbod]

On 03/15/2009 10:00 AM, Kenneth Nielsen wrote:

doesn't have it, there's good reason for it.

Like what?

Why does it matter?


Well if there is no good reason, then it would sure make my job easier
if they could comply, so I could commit to all modules in the same
way. Remember that I have to commit to more than 80 modules.


There is good reason.  I don't see how it's relevant to whether you should 
edit ChangeLog.preX.Y or not.  How is editing that wrong file making your job 
easier?


Easier or not, if a module doesn't have ChangeLog, it doesn't.  If you don't 
like that, file a bug against them.


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

Re: Don't add ChangeLog entries to ChangeLog-less modules

[Behdad Esfahbod]

On 03/15/2009 09:49 AM, Kenneth Nielsen wrote:

2009/3/15 Behdad Esfahbod:

On 03/15/2009 09:44 AM, Jorge González González wrote:

Hi,

El dom, 15-03-2009 a las 14:30 +0100, Christian Persch escribió:

Hi;

Absence of ChangeLog, po/ChangeLog and help/ChangeLog etc. means that
the module in question does not use changelogs. (For example,
this is the case for epiphany, epiphany-extensions, gucharmap,
gnome-terminal, gnome-games.) However, some translators still add
changelog entries to modules that do not have ChangeLog files, adding
them to po/ChangeLog.pre-X-Y or ChangeLog.old etc. These files are, as
their name already indicates, not to be modified further. Please stop
doing this.


didn't we agree that the standard was to have them?

What standard?  The norm currently is to have them, yes.  But if a module
doesn't have it, there's good reason for it.


Like what?


Why does it matter?

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

Re: Don't add ChangeLog entries to ChangeLog-less modules

[Behdad Esfahbod]

On 03/15/2009 09:44 AM, Jorge González González wrote:

Hi,

El dom, 15-03-2009 a las 14:30 +0100, Christian Persch escribió:

Hi;

Absence of ChangeLog, po/ChangeLog and help/ChangeLog etc. means that
the module in question does not use changelogs. (For example,
this is the case for epiphany, epiphany-extensions, gucharmap,
gnome-terminal, gnome-games.) However, some translators still add
changelog entries to modules that do not have ChangeLog files, adding
them to po/ChangeLog.pre-X-Y or ChangeLog.old etc. These files are, as
their name already indicates, not to be modified further. Please stop
doing this.

>

didn't we agree that the standard was to have them?


What standard?  The norm currently is to have them, yes.  But if a module 
doesn't have it, there's good reason for it.


Thanks,
behdad




Regards,
Christian

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

Re: What can Git do for translators?

[Behdad Esfahbod]

Leonardo F. Fontenelle wrote:

> As a translator, I just have to check out the po/ or help/ subdirs where
> I want to commit my translation files to. There's even a LINGUAS file in
> the po/ subdirs to avoid translators checking out the whole module just
> to edit Makefile.am.

The main reason to move to LINGUAS was in fact to make it less error prune for
translators.  Previously we were left with many broken builds because, eg, the
editor decided to break the line and the translator (not exactly savvy in
configure.ac syntax) didn't notice.

> AFAIK moving to git would mean committers must checkout the whole
> module.

That's assuming that the transition team does not find a solution to this
problem.  Lets not speculate and focus on the problems that need to be solved.
 That's why Federico is here asking you what your workflow is.  If the
transition happens and you are left in the cold having to download the full
module to commit one file, you have all rights to complain :).

Cheers,

behdad

> If it can't be worked around, it will be a major problem for
> most translation teams. Brazil is not exactly a poor country, and
> 128kbps is still called "broadband" here.
> 
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: msgctxt conversion for 2.26 ?

[Behdad Esfahbod]

Christian Rose wrote:
> On 11/6/08, Petr Kovar <[EMAIL PROTECTED]> wrote:
>>  > And, what does the members of the Coordination Team think?

Who's Coordination Team? :)

>> I guess that no reply from the people asked above actually means, "we
>>  don't care, or we don't have time to care". (We could also think
>>  whether it is good for us if the coordinators don't care, or not, but
>>  anyway...)

That's not the case.  No reply more often than not means "no objection".

>>  Can we come to the point now and perform the needed action?
> 
> There you go, I have proposed it now:
> http://mail.gnome.org/archives/desktop-devel-list/2008-November/msg00218.html

Indeed.  The way GNOME Goals work is:

  - You write up a draft and propose it (and request review at the same time)

  - People shout if it's a bad idea

  - If no one shouts, or after you resolve the issues raised, you send it out
and try to get a mass going on to convert all modules.

First rule of Coordination Team is...  Nevermind.

behdad

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

Re: Cultural Issue with the Foot Logo

[Behdad Esfahbod]

Gudmund Areskoug wrote:
> Hello,
> 
> 2008/10/30 F Wolff <[EMAIL PROTECTED]>:
>> On Do, 2008-10-30 at 13:27 +0700, Theppitak Karoonboonyanan wrote:
>>> Dear gnome-i18n,
>>>
>>> I believe this is an appropriate place to discuss about cultural
>>> conventions.
>>>
>>> How is a foot interpreted in your culture? Do you have the same
>>> issue I have met? In my culture, showing foot is considered rude.
>>> And the foot is not something to impress people who are totally new
>>> to GNOME.
> 
> just FWIW, the foot is or has been considered rude or even a heavy
> insult (duel fodder) in a number of cultures.

There's little information in that sentence without backing it up with real
names and (hopefully) evidence.

behdad

>> I assume that culturally sensitive graphical design is hard, and I guess
>> you are used to simply taking what you get as a Thai translator. If we
>> say we are an international group, we should try to accommodate this
>> difference as much as we work on text layout, GUI translation, date
>> formats, etc.
> 
> Agree, but partly, like Matej says, it's in the eye of the beholder,
> and partly it's a matter of resources.
> 
> I think no alternative logos will appear until people start submitting them.
> 
>> I think I know of at least one team that doesn't translate and promote
>> Firefox under that brand, since the fox is considered negative in their
>> culture - I guess for Mozilla there is too much in that brand to dilute
>> it, but they lost that team (in as far as I know).
> 
> This is a pity and if true even a bit silly. The firefox isn't a fox,
> it's a panda:
> 
> 
> This is the animal that would turn up all across the field, before
> Mozilla Firefox popularity overwhelmed all the search engines.
> 
> BR,
> Gudmund
> ___
> 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: Licenses of .po files, and translations

[Behdad Esfahbod]

Gora Mohanty wrote:
> Yes, the copyright undoubtedly belongs to the translator. The
> question involves licensing terms. If the .pot file was under
> the GPL, is the .po file a derivative work, and hence under
> the GPL, too? A secondary question is, if an existing .po
> file, which is explicitly licensed under the GPL, is added to
> by another translator, is the new translation also under the
> GPL?

IANAL, but there's not much room for one's personal opinion here.  The PO
file, no matter how many translators touch it, is definitely a derivative work
of the source code, via the POT file.  The evidence: pieces of the source code
(namely the strings) are still in there, how can this not be a derivative
work?!  Given that, if the source code is GPL'ed, there's no choice left for
the translator.  If he or she distributes the derived work (that is, the
translation) in a license other than GPL it's a violation of the GPL.

There is belief misconception that if someone contributes for an existing
work, he gets to choose under which license his contributions are.  This is
definitely true, but the choices he has are most of the time very, very, 
limited.

behdad

> My opinion would be yes, in both cases, though it is much less
> clear in the first case. There, since the strings are derived
> from the source code, and since the .pot file says that the
> licence is the same as that for the base package, my opinion
> is that if the application is under the GPL, so is the .pot file.
> 
> Maybe we should get a legal opinion on this.
> 
> Regards,
> Gora
> ___
> 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: Review needed for Pango language sample strings

[Behdad Esfahbod]

Gora Mohanty wrote:
> On Tue, 26 Aug 2008 18:12:51 -0400
> Behdad Esfahbod <[EMAIL PROTECTED]> wrote:
> 
>> Hi,
>>
>> Pango keeps a single string (sentence) per language that it uses
>> internally and also exposes for other applications to use (in a
>> font dialog for example).
> [...]
>> I'm now asking translation teams to review the sentence for
>> their language now.  Please file a bug against pango at
>> http://bugzilla.gnome.org/ if you think a sample string
>> needs to be changed.
> [...]
> 
> The Hindi string as it stands looks good, except for a small
> error in the word that is third from last. Have filed a bug,

Thanks Gora.  I don't see the bug though.  Did you file it against Pango or
against Hindi localization?  Please move it to Pango so I see it.

behdad


> and also another one from Oriya, a language missing from the
> list. Have also forwarded your message to the IndLinux mailing
> list, so that speakers of other Indian languages can chime in.
> 
> Regards,
> Gora
> ___
> 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: Review needed for Pango language sample strings

[Behdad Esfahbod]

Leonardo F. Fontenelle wrote:
> The Brazilian Portugues pangram is good but has no diacritcs. As a
> Brazilian I don't bother to check if a particular software or font
> supports them; it is very likely that it will do a good job. But, if you
> want to put enphasis on the diacritics, please consider if this phrase
> is short enough:
> 
> À noite, vovô Kowalsky vê o ímã cair no pé do pingüim queixoso e vovó
> põe açúcar no chá de tâmaras do jabuti feliz.

This looks good.

> If the string lenght is OK I can open a bug report with a patch.

Patch would be nice, yeah.  I can do the patches myself though if one opens a
bug and leaves me the phrase and English translation.

So yeah, even if not sure, please open the bug.  That makes it easier for me
to track them all and not lose anyone's suggestion.

Cheers,

behdad

> Em Ter, 2008-08-26 às 18:12 -0400, Behdad Esfahbod escreveu:
>> Hi,
>>
>> Pango keeps a single string (sentence) per language that it uses internally
>> and also exposes for other applications to use (in a font dialog for 
>> example).
>>  Previously the sample text were quite limited (about 20 language supported),
>> and bogus.  I have not extended the list to about a hundred tables.  I used
>> various sample-string, pangram, and other resources freely available.  These
>> can be found here:
>>
>> http://svn.gnome.org/viewvc/pango/trunk/pango/pango-language-sample-table.h?view=markup
>>
>> I'm now asking translation teams to review the sentence for their language
>> now.  Please file a bug against pango at http://bugzilla.gnome.org/ if you
>> think a sample string needs to be changed.  A good sample string would be:
>>
>>   - Politically correct
>>
>>   - Representative of normal text in the language (so, no alphabetical lists)
>>
>>   - Exposes features unique to the language (European sample strings would 
>> use
>> diacritics used in the target language for example)
>>
>>   - Not too short, not too long
>>
>>   - Not copied from what Windows uses (unless it's a very widespread thing
>> like "The quick brown fox..."
> 
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Review needed for Pango language sample strings

[Behdad Esfahbod]

Hi,

Pango keeps a single string (sentence) per language that it uses internally
and also exposes for other applications to use (in a font dialog for example).
 Previously the sample text were quite limited (about 20 language supported),
and bogus.  I have not extended the list to about a hundred tables.  I used
various sample-string, pangram, and other resources freely available.  These
can be found here:

http://svn.gnome.org/viewvc/pango/trunk/pango/pango-language-sample-table.h?view=markup

I'm now asking translation teams to review the sentence for their language
now.  Please file a bug against pango at http://bugzilla.gnome.org/ if you
think a sample string needs to be changed.  A good sample string would be:

  - Politically correct

  - Representative of normal text in the language (so, no alphabetical lists)

  - Exposes features unique to the language (European sample strings would use
diacritics used in the target language for example)

  - Not too short, not too long

  - Not copied from what Windows uses (unless it's a very widespread thing
like "The quick brown fox..."


That's it.  Thanks in advance,

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

Re: major libgweather Locations updates

[Behdad Esfahbod]

On Tue, 2008-08-05 at 21:42 +0300, Александър Шопов wrote:
> This immense change is something that I personally do not approve of. 
> Translating cities, huts, hamlets and jerk water somewhere is no
> particular fun. And there is no particular use of this.
> I as a coordinator of the Bulgarian Gnome project am putting translation
> of the places in gweather in the trash.
> The developers of gweather can scrape atlases and maps for whatever
> damn, uninhabited place on Earth (or Moon actually, why the smeg is Mare
> Tranquillitatis missing from gweather?) or stranded military base.
> Life is way too short for this shit.
> The least they could have done is to have provided us with IPA
> transcriptions.
> I cannot think of any motif for their deed but the direst passion to be
> blogged about in linuxhaters.
> Come on guys, you could have contacted the team there directly, no need
> for such convoluted ways. This is not the incredible machine, you are
> not Rube Goldberg.
> al_shopov

Please keep your rants to yourself, or just send to linuxhaters
directly.  This kind of language is *not* appreciated.  Neither by
gweather developers, nor by other translators, or any other member of
the project, or really, any sane person.

-- 
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

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

Re: Slowness in farsi translation

[Behdad Esfahbod]

On Tue, 2008-07-01 at 11:48 -0700, Roozbeh Pournader wrote:

> > 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?

I never ran Sharif Linux, so I don't even know how the translations
there look like, but I'm sure what has happened is:

  - FarsiWeb translated GNOME circa 2.14 to over 80% at which point
Persian was marked "supported" in GNOME.  FarsiWeb also released Sharif
Linux based on that.  As one expects from a Linux distribution of a
minimum quality control, Sharif Linux's default desktop was fully
translated.

  - FarsiWeb then moved resources out of translation work, that resulted
in Persian stats going down over two or more release cycle to the
seventy-something that they stand now.

  - Ubuntu shipped GNOME, but then changed some words, namely, the
infamous menu name change from whatever it was in upstream GNOME to
"System".  That showed up untranslated in the Persian desktop.


I find the whole idea of attacking the GNOME Persian translation team
based on quality of Persian support shipped on a distro like Ubuntu
which is notorious for making upstream-unhappy changes quite ridiculous.
Moreover, Sharif Linux is a Free Software distro.  Anyone in Iran can
buy it for a modest price and request the source code, blah blah.

To summarize:
All conspiracy theories and no code makes for an unhealthy way to
collaborate.


-- 
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

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

Re: New team for Dari (prs)

[Behdad Esfahbod]

On Wed, 2008-06-25 at 16:16 +0300, Khaled Hosny wrote:
> On Wed, Jun 25, 2008 at 08:43:07AM -0400, Behdad Esfahbod wrote:
> > On Wed, 2008-06-25 at 08:07 +0300, Tommi Vainikainen wrote:
> ...
> > > According to Wikipedia (http://en.wikipedia.org/wiki/Dari_%28Persian%29)
> > > this Dari language is also spoken in Pakistan, Tajikistan and
> > > Turkmenistan. Should Dari speakers in those countries use country code
> > > _AF as their locale? Isn't such usage problematic in many ways?
> > > 
> > > Therefore I argue that technically it is better to use three letter
> > > language codes if ISO standard has assigned a separate code, because
> > > then there is no disambiguity of using country codes etc.
> > 
> > Yeah, like, because English is spoken in so many countries, why do we
> > have en_US, en_CA, en_UK, ...?
> 
> What about the case like Arabic where we have one common "ar" locale
> where all translations reside, and several "ar_XX" locales per country 
> to allow different locale settings. If Dari is spoken in different
> countries, it might not be a good idea to force all Dari speakers to
> use one single locale.

Sure, but I'm not sure that the Afghan and Tajik use the exact same
language.  Both are part of a family called Dari, aka Eastern Persian,
as opposed to Iranian Persian which is called Western Persian.

Others prefer to call the language used in Tajikistan Tajik, to
distinguish it from the Afghan version.  Both are fairly recognizable by
a native of Iran.  And Iranian Persian is recognizable by both Afghans
and Tajiks.  The root language is really "fa", as Roozbeh suggested.
Quoting [1]:

fas is the ISO 639-3 language code for Persian. Its ISO 639-1 code is
fa. There are 2 individual language codes assigned:

 1. prs — Dari Persian
 2. pes — Western Persian


So, should we use change the "fa" translations to "pes"?  No.
Note that ISO639-3 codes are more of scholarly interest.  Also according
to [2], both "prd" and "prs" are ISO639-3 language codes for "Persian
(Dari)".  No idea what the difference is.


[1] http://en.wikipedia.org/wiki/ISO_639_macrolanguage


> Regards,
>  Khaled

-- 
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

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

Re: New team for Dari (prs)

[Behdad Esfahbod]

On Wed, 2008-06-25 at 08:07 +0300, Tommi Vainikainen wrote:
> "Roozbeh Pournader" <[EMAIL PROTECTED]> writes:
> > On Mon, Jun 23, 2008 at 9:49 PM, Mazdak Kiani <[EMAIL PROTECTED]> wrote:
> >> My language ISO 639-3 code is prs:
> >>
> >>  http://www.sil.org/iso639-3/documentation.asp?id=prs
> >>  http://www.ethnologue.com/show_language.asp?code=prs
> >
> > When we can use ISO 639-1 language codes, we should use those. ISO
> > 639-3 should only be used when a code does not exist.
> 
> At least such "should" is not documented on GNOME's wiki.

Any language needs to get a libc locale first, and these restrictions
are enforced there.


> > Locale projects, including Unicode CLDR, use fa_AF for Dari. For
> > example, see here:
> 
> According to Wikipedia (http://en.wikipedia.org/wiki/Dari_%28Persian%29)
> this Dari language is also spoken in Pakistan, Tajikistan and
> Turkmenistan. Should Dari speakers in those countries use country code
> _AF as their locale? Isn't such usage problematic in many ways?
> 
> Therefore I argue that technically it is better to use three letter
> language codes if ISO standard has assigned a separate code, because
> then there is no disambiguity of using country codes etc.

Yeah, like, because English is spoken in so many countries, why do we
have en_US, en_CA, en_UK, ...?


-- 
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

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

Re: Slowness in farsi translation

[Behdad Esfahbod]

On Tue, 2008-06-24 at 13:33 +0430, Mohammad Foroughi wrote:
> 
> You don't have time
> Roozbeh don't have time
> Elnaz don't have time
> 
> So, who should complete translations?

You do, instead of writing mails to gnome-i18n.

> It seems that you are a kind of monopolist translator. Why you do not
> let others help WHEN YOU  ARE BUSY???

What the fuck?  Go translate and submit to bugzilla instead of nagging.

-- 
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

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

Re: Slowness in farsi translation

[Behdad Esfahbod]

On Tue, 2008-06-24 at 10:17 +0430, Mohammad Foroughi wrote:
> Hi all,
> 
>  It seems that the process of translating gnome into persian is slow. I
> asked Behnam Esfahbod and he told me that there is only 2 active members
> in the team: Mr. pournader commits translations and his wife reviews
> them.
> 
>  http://bugzilla.gnome.org/buglist.cgi?product=l10n&component=Persian
> [fa]&bug_status=NEW&bug_status=REOPENED&bug_status=ASSIGNED&bug_status=UNCONFIRMED
> 
>  In the above link you can see the amount of work done but did not
> reviewd or commited.
> 
>  Why mr. pournader do not allow others to review or commit? It will
> speedup translation process.
> 
>  He can use experienced translators from HIS team, like Behdad Esfahbod,
> Behnam Esfahbod and others.

I don't have time for this right now.


>  And if they are busy too, he can use people like Mirdamadi and others
> from ubuntu persian team (coordinated by behnam esfahbod), it seems that
> they have free time and can work, also they are EXPERIENCED TRANSLATORS.

If they have free time and are EXPERIENCED TRANSLATORS, why don't they
fully complete Ubuntu's Persian translation?  Then you get what you
wanted, right?

Moreover, instead of SHOUTING, show us why you think they are
EXPERIENCED TRANSLATORS.  I've been around the Free Software Persian
computing scene for the past eight years and never heard of the person
you mention..


>  So, Roozbeh, please let others help you...

The way to help, as has been repeatedly pointed out to you, is to submit
your translations and be patient.  This is how our code is written, and
this should be how our translation is done.

Freedom does not mean anarchy.  Get over it.


> Best Regards,
> Mohammad Foroughi

-- 
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

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

Re: New team for Dari (prs)

[Behdad Esfahbod]

On Mon, 2008-06-23 at 21:49 -0700, Mazdak Kiani wrote:
> My language ISO 639-3 code is prs:

Then please tell us who speaks this language and where.


-- 
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

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

Re: A coordinator with very long response time

[Behdad Esfahbod]

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

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

Re: A coordinator with very long response time

[Behdad Esfahbod]

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
-- 
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

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

Re: A coordinator with very long response time

[Behdad Esfahbod]

Hi Mohammad,

On Wed, 2008-05-14 at 09:00 +0430, Mohammad Foroughi wrote:

> So PLEASE tell me how can I contribute to gnome translation?

You contribute to GNOME by submitting your contribution as you have been
doing in the past couple of weeks.

> Hi didn't submit my translations (http://417.ir/po) and asked others
> not to submit

You are confusing "submit" with "commit".  As a contributor, you
submitted your work and we appreciate it.  It's up to the maintainer or
other, more experienced members of the team to review and commit it.
You can get commit access *after* you show your competency and a certain
level of commitment to the project.  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.

> If he is busy, he SHOULD resign and you must select another
> coordinator.

Lets say he resigns today, and I become coordinator.  How does that
help?  Or who do you have in mind as his replacement?  If it's yourself,
I'm afraid that's not the way it works.

Lets just continue constructive work.

Cheers,

-- 
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

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

Re: new mailing list

[Behdad Esfahbod]

On Sat, 2008-04-19 at 20:46 +0430, Mostafa Daneshvar wrote:
> Hi 
> I think Farsi team needs a separate mailing list. Hereby I ask guys to setup 
> a 
> new mailing list for discusion in Persian matters.

Fully agreed.  There has been serious issues with using lists not hosted
on GNOME facilities before.  Lets just use the unused
[EMAIL PROTECTED]   I will personally administer the list and
ensure its health.  I will update the list info page on Monday to
reflect this new use.  All people interested should go ahead and
subscribe now.  

-- 
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

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

Re: pango and gucharmap

[Behdad Esfahbod]

On Wed, 2008-04-09 at 19:21 +0100, Simos Xenitellis wrote:
> 
> Q. Anyway, are there fonts available for these new Unicode scripts?

This is a GNOME release, not a Fedora release.  By releasing a Unicode
5.1 gucharmap now we actually help people develop fonts for the new
scripts.

-- 
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

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

Re: pango and gucharmap

[Behdad Esfahbod]

On Wed, 2008-04-09 at 18:00 +0200, Christian Persch wrote:
> Hi;
> 
> the new strings would be these unicode script and block names:

Most of these are names of minority scripts newly encoded in Unicode.  I
don't know the Persian translation for most them.  I expect the same for
most language teams...

behdad


> >  +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"
> 
> Regards,
>   Christian
> 
-- 
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

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

Re: pango and gucharmap

[Behdad Esfahbod]

On Wed, 2008-04-09 at 17:26 +0200, Vincent Untz wrote:
> Le mercredi 09 avril 2008, à 09:28 -0500, Behdad Esfahbod a écrit :
> > On Wed, 2008-04-09 at 11:32 +0200, Vincent Untz wrote:
> > > Le mercredi 09 avril 2008, à 04:29 +0430, Behnam Esfahbod a écrit :
> > > > Hey guys,
> > > > 
> > > > On Wed, Apr 9, 2008 at 3:49 AM, Christian Persch <[EMAIL PROTECTED]> 
> > > > wrote:
> > > > >  I already updated gucharmap trunk to 5.1, but I didn't update the
> > > > >  gnome-2-22 branch since the update introduces 17 new strings. So I 
> > > > > don't
> > > > >  think we can take that change for 2.22.1...
> > > > 
> > > > IIRC string addition is allowed after string-freeze; we had similar
> > > > situation for UCD 5.0.  Doesn't that apply on minor updates as well?
> > > 
> > > No, string addition is not allowed after string freeze, except when the
> > > string was already there but not marked for translations.
> > 
> > I'd rather we have untranslated names for the scripts newly encoded in
> > Unicode than not having Unicode 5.1 data in GNOME *less than a week
> > after Unicode 5.1 is released*.
> 
> Let's cc gnome-i18n and see what translators think :-)

So I hereby request string freeze break for gucharmap...

> Vincent
> 
-- 
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

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

Re: Copyright assignment policy

[Behdad Esfahbod]

[CC'ing gnome-i18n]

On Tue, 2008-03-11 at 14:24 +0200, [EMAIL PROTECTED] wrote:
> 
> I am Alexander Shopov and I act as a co-ordinator of the Bulgarian Gnome
> translation team.
> 
> Up till now, the copyrights have been assigned to the Free Software 
> Foundation, Inc.
> 
> I have personally contacted the individual contributors who gave me their
> permission (informal) to change the copyright assignments in the po-files for
> those translators that had retained copyright and assign that to FSF.

Don't do that.  That adds an unnecessary barrier to entry, and you are
essentially taking their contribution away from them.

-- 
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

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

Re: Request for resolving situation(kn_IN)

[Behdad Esfahbod]

On Thu, 2008-03-13 at 13:08 +0100, Behdad Esfahbod wrote:
> Given Vikram's prompt reply, I
> don't see any of those problems with your team.

I meant Pramod's of course.

-- 
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

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

Re: Request for resolving situation(kn_IN)

[Behdad Esfahbod]

On Thu, 2008-03-13 at 17:33 +0530, Vikram Vincent wrote:
> 
> Just a few weeks ago the stats for Kannada showed 16%
> translated(anybody can verify this) and suddenly it jumped to 50%. Do
> you know how much work you forced us to duplicate?

Then there's a communication problem.  Is there a mailing list for your
translation team?  If not, ask for one.  It wouldn't have prevented
duplicate work if you were the coordinator either.

-- 
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

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

Re: Request for resolving situation(kn_IN)

[Behdad Esfahbod]

On Thu, 2008-03-13 at 17:31 +0530, Vikram Vincent wrote:

> On 13/03/2008, Pramod R <[EMAIL PROTECTED]> wrote:
> --- Vikram Vincent <[EMAIL PROTECTED]> wrote:
> 
> I don't understand how this is so complicated. For
> one, I do welcome your efforts in getting the
> translations done, (although I have not seen the same
> committed), I would be happy to commit it. And if you
> think, you want to commit on your own, I would not
> mind if you apply for a SVN account and let me know. I
> frankly don't see why you need a Co-ordinatorship for this.
> Why?
> -> To prevent duplication of effort. This is imperative considering
> that Shankar and yourself are doing work offline and committing at
> not-defined intervals. And we are doing work online and trying to
> reduce the entry barrier.
> Question:
> As coordinator, how do you propose to coordinate in this
> situation(whether GNOME or OPenOffice or Aspell or anything else)?

As Pramod said, you can get SVN commit access and commit directly.
That's pretty much all there is to it.  The coordinator has not magic
powers or anything.

I understand that people are tempted to claim coordinator status when
they become the most active contributor, but the logic behind that claim
does not necessarily hold.  A coordinator is not even supposed to be the
most active translator at all.  [S]He's a "coordinator".  You should
complain about it when your coordinator does not respond or makes it
hard for contributors to contribute.  Given Vikram's prompt reply, I
don't see any of those problems with your team.

My 0.02€

-- 
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

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

gnome-terminal branched for gnome 2.20

[Behdad Esfahbod]

The branch name is gnome-2-20.


-- 
behdad
http://behdad.org/

...very few phenomena can pull someone out of Deep Hack Mode, with two
noted exceptions: being struck by lightning, or worse, your *computer*
being struck by lightning.  -- Matt Welsh

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

Re: Argh.. Novell people imports external translations again

[Behdad Esfahbod]

On Sat, 2007-09-15 at 19:25 +0200, Robert-André Mauchin wrote:
> Le samedi 15 septembre 2007 à 18:24 +0200, Daniel Nylander a écrit :
> > 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.
> > 
> 
> He messed up the typopography in the french file too (english quotation
> and nbsp missing). It has to be reverted. 

When contacting him, please also ask him to copy his ChangeLog changes
as commit messages.  Gr...

behdad

PS. Ok, CC'ing him.

> Thanks.
> 
> Bob.
> 
> Note :
> http://svn.gnome.org/viewcvs/gnome-main-menu/trunk/po/fr.po?r1=253&r2=339
> 
> 
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-i18n
-- 
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



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

Re: Strange abbreviation in Dasher

[Behdad Esfahbod]

On Sat, 2007-09-01 at 10:36 +0300, Alexander Shopov wrote:
> What does PPM stand for in Dasher?
> 
> http://bugzilla.gnome.org/show_bug.cgi?id=472454

"Prediction by Partial Matching".  That's exactly what Dasher does.

http://en.wikipedia.org/wiki/Prediction_by_Partial_Matching


> al_shopov

-- 
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



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

Re: language list

[Behdad Esfahbod]

On Sun, 2007-07-08 at 22:00 +0200, Nacho wrote:
> Hi all,
> I am looking for a language list with this information:
>  * language name
>  * locale (e.g. gl)
>  * encoding
>  * group's email
>  * transfer bit count for the language (e.g. 8bit)
>  * number of plurals 
>  * and plural form string.
> 
> Where can i find it?

In the header of translation .po files for, say, glib.  But many of the
fields may be inaccurate (email address, etc).

> Regards.

-- 
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



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

Re: Formatting lists of things

[Behdad Esfahbod]

On Sat, 2007-06-23 at 14:12 +0200, Claude Paroz wrote:
> Le samedi 23 juin 2007 à 13:35 +0200, Wouter Bolsterlee a écrit :
> > 2007-06-22 klockan 17:23 skrev Shaun McCance:
> > > 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
> > 
> > Dutch (both nl_NL and nl_BE) practice is to omit the last comma. Your
> > example as they would be written in Dutch:
> > 
> >   Tom and Dick
> >   Tom, Dick and Harry
> >   Tom, Dick, Harry and Sally
> 
> I guess this is more or less the same with most European languages. What
> about other languages, Djihed, Yaïr, Abel ?
> 
> Claude

It's the same in Persian too (which was based on French), but more
modern styles (in academia for example) have started keeping the last
comma.  It just makes more sense and is less ambiguous.

-- 
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



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

gucharmap branched for gnome-2-16

[Behdad Esfahbod]

The branch name is gnome-2-16 and it's based on gucharmap-1.8.0
Please update.
-- 
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



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

Re: Help with a RTL issue

[Behdad Esfahbod]

On Fri, 2007-02-09 at 01:22 -0300, Mariano Suárez-Alvarez wrote:
> 
> 
> I could handle this in code, asking gtk what the text direction is for
> the menu widget and interchaning the strings corresponding to Left and
> Right. But I do not know if this is good enough in all languages.

Yeah, this is good enough, and doesn't depend on translators reading the
comments and interchanging translations.

> So: how does one usually deal with this problem?
> 
-- 
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



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

Re: RTL support in Gnome

[Behdad Esfahbod]

On Wed, 2007-01-17 at 21:15 -0500, Owen Taylor wrote:
> 
> 
> And how would this differ significantly in practice from
> gtk-i18n-list?
> - Owen 

People can discuss issues in Evolution, gnome-panel, Nautilus, GIMP,
other apps...  So far I've only seen such stuff on bugzilla.  Or is that
ok on gtk-devel-list?

-- 
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



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

Re: RTL support in Gnome

[Behdad Esfahbod]

On Wed, 2007-01-17 at 13:26 -0600, Shaun McCance wrote:
> 
> Unfortunately, gnome-i18n has already become the de facto
> list for l10n, so naming a new i18n list would be tricky.

gnome-i18n-devel?

-- 
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



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

Re: RTL support in Gnome

[Behdad Esfahbod]

On Wed, 2007-01-17 at 08:41 +, Kjartan Maraas wrote:
> 
> Isn't this really just a specialized group within the i18n team? Can't
> it be solved there without creating yet another list, keyword in
> bugzilla etc etc?

Right.  But gnome-i18n has turned into being a translation-only kind of
list, and gtk-i18n-list is too lowlevel...

-- 
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



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

Re: RTL support in Gnome

[Behdad Esfahbod]

On Tue, 2007-01-16 at 11:39 +0200, Yair Hershkovitz wrote:
> Hi,
> 
> I've been working lately on some bugs with RTL (right to left
> languages) support in Gnome.

Thanks Yair for the work.

> I have few suggestions to help improve RTL support in Gnome:
> 
>   1) I want to start a mailing list for RTL support discussions
> ( [EMAIL PROTECTED] ???)

I don't think it's quite necessary.  One reason is that only people
directly interested in RTL support will be there, while most of the time
one wants comment from main developers of modules or other "interested"
hackers.  You don't get it there.

>   2) I think we should add an "rtl" keyword to bugzilla, for tracking
> RTL issues.

We've been using a tracker bug for everything blocking perfect Persian
support in GNOME for some while, and it's been quite handy.  It's
aliased 'persian':

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

I suggest you create an aliased tracker too.  When you want to add this
"keyword" to a bug, you just add "persian" to the bugs it blocks...

However, I think you may just want to follow the 'persian' bug.  Almost
everything related to RTL support is listed there, and the
Persian-specific stuff is not that much.

> Tnx,
> Yair.

Regards,
-- 
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



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

vte branched for GNOME 2.16

[Behdad Esfahbod]

I just branched vte off the 0.14.1 version named gnome-2-16.  Stable
releases will continue from that branch.  Please update.

-- 
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



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

Re: GnomeDocUtilsMigrationHowTo improvements

[Behdad Esfahbod]

On Sun, 2006-09-03 at 09:57 -0400, Emmanuele Bassi wrote:
> Hi Behdad;
> 
> On Sun, 2006-09-03 at 04:36 -0400, Behdad Esfahbod wrote:
> 
> > There are also a couple of technical problems with that document.  One
> > is:
> > 
> > 
> > Set your build system up: 
> >   * If you don't have one yet, create a m4 directory in your
> > toplevel source directory; and create a .cvsignore file in it
> > containing at least gnome-doc-utils.m4. Add this directory and
> > its .cvsignore to cvs. 
> > 
> >   * Add the following to configure.ac (resp. configure.in): 
> > 
> >   * AC_CONFIG_MACRO_DIR([m4])
> >   * Add m4 to EXTRA_DIST in the top-level Makefile.am See below Note 2
> > 
> > 
> > This is absolutely unnecessary, and it does create problems.  A lot.
> 
> I added that section as a result of what I did learn when porting
> gnome-utils to gnome-doc-utils; at the moment of the porting, if I did
> not include the macro directory in the EXTRA_DIST, make distcheck would
> fail (I did various checks and the only change that affected the outcome
> of distcheck was that).  Lately, I was able to pass the distcheck phase
> even when the m4 directory was not inside the EXTRA_DIST variable - so I
> think that porting my build environment to automake >= 1.7 did the
> trick.

I'm not referring to the EXTRA_DIST part in particular, but the entire
idea of enabling a MACRO_DIR.  AFAIU a MACRO_DIR should be used when you
want to use and distribute home-made macro files that may not be
available on the system.  I don't see any reason that one should do
that.  If the intention to make sure packages can be autogen'ed without
gnome-doc-utils?  I don't think that's important enough to warrant
adding a directory to all modules.


> I think it's safe to assume that yes: that bit is wrong when using an
> automake < 1.7; I'd like people with older versions of automake to test
> that bit and see if it was just a screw up in my build environment.
> 
> Ciao,
>  Emmanuele.
> 
-- 
behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"

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

GnomeDocUtilsMigrationHowTo improvements

[Behdad Esfahbod]

Hi,

Hope these are the right lists to write to.  I would like to suggest
some improvements in the GnomeDocUtilsMigrationHowTo document [1].
Warning: rants following.

First problem is: translators go on and convert translations for a
language in a module to GnomeDocUtils, remove the
help//Makefile.am file and walk away happily, leaving a broken
build behind...  Has happened quite a few times to me, including today
[2].

There are also a couple of technical problems with that document.  One
is:


Set your build system up: 
  * If you don't have one yet, create a m4 directory in your
toplevel source directory; and create a .cvsignore file in it
containing at least gnome-doc-utils.m4. Add this directory and
its .cvsignore to cvs. 

  * Add the following to configure.ac (resp. configure.in): 

  * AC_CONFIG_MACRO_DIR([m4])
  * Add m4 to EXTRA_DIST in the top-level Makefile.am See below Note 2


This is absolutely unnecessary, and it does create problems.  A lot.


Finally, as noted by Mariano [2], the "--disable-scrollkeeper to
DISTCHECK_CONFIGURE_FLAGS in the top-level Makefile.am" part is also not
necessary.  scrollkeeper has never kept make distcheck from running.
Not recently enough that I've seen FWIW.


rants off,
behdad


[1] http://live.gnome.org/GnomeDocUtilsMigrationHowTo
[2] http://bugzilla.gnome.org/show_bug.cgi?id=354056

-- 
behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"

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

Re: GTK+: Optional translation of %d to %d or %ld breaks PO file

[Behdad Esfahbod]

On Sat, 2006-09-02 at 18:00 -0400, Åsmund Skjæveland wrote:
> > > 877 translated messages, 2 untranslated messages.
> > > *
> > > *** ERROR MESSAGE FROM Gnome Translation Team ***
> > > *
> > > You are trying to commit an invalid .po file!
> > > Please verify it first with msgfmt. Any problems
> > > please contact .
> > > 
> > > nn.po:1169: 'msgstr' is not a valid C format string, unlike 'msgid'
> > > nn.po:1185: 'msgstr' is not a valid C format string, unlike 'msgid'
> > > msgfmt: found 2 fatal errors
> > > cvs server: Pre-commit check failed
> > > cvs [server aborted]: correct above errors first!
> > > 
> > > I use gettext 0.14.5. I don't know what GNOME CVS uses.
> > 
> > Check my comment in the bug:
> > 
> >   http://bugzilla.gnome.org/show_bug.cgi?id=312694
> 
> Bug 312694  Character popup is inaccessible using twm
> 
> I've read it three times now, and I can't see how this is relevant.

Sorry, copy/paste messup.  I meant the bug you opened yourself:

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

-- 
behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"

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

Re: GTK+: Optional translation of %d to %d or %ld breaks PO file

[Behdad Esfahbod]

On Sat, 2006-09-02 at 14:15 -0400, Åsmund Skjæveland wrote:
> On Sat, Sep 02, 2006 at 07:49:11PM +0300, [EMAIL PROTECTED] wrote:
> > On 2006-09-02T18:57:41+0300, [EMAIL PROTECTED] wrote:
> > > #. Translators: this defines whether the week numbers should use
> > > #. * localized digits or the ones used in English (0123...).
> > > #. *
> > > #. * Translate to "%Id" if you want to use localized digits, or
> > >
> > > This doesn't work. If I translate to "%ld", msgfmt barfs and declares
> > > the PO file broken. 
> > 
> > It is %Id not %ld (a big 'i', not a small 'l'). Maybe this helps you?
> 
> Good point. When I put "%Id", my msgfmt accepted the file. However, I
> believe the bug still is real, since GNOME CVS refuses my file:
> 
> 877 translated messages, 2 untranslated messages.
> *
> *** ERROR MESSAGE FROM Gnome Translation Team ***
> *
> You are trying to commit an invalid .po file!
> Please verify it first with msgfmt. Any problems
> please contact .
> 
> nn.po:1169: 'msgstr' is not a valid C format string, unlike 'msgid'
> nn.po:1185: 'msgstr' is not a valid C format string, unlike 'msgid'
> msgfmt: found 2 fatal errors
> cvs server: Pre-commit check failed
> cvs [server aborted]: correct above errors first!
> 
> I use gettext 0.14.5. I don't know what GNOME CVS uses.

Check my comment in the bug:

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

-- 
behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"

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

Re: GTK+: Optional translation of %d to %d or %ld breaks PO file

[Behdad Esfahbod]

On Sat, 2006-09-02 at 11:57 -0400, Åsmund Skjæveland wrote:
> In gtk+ branch gtk-2-10 there is this msgid:
> 
> #. Translators: this defines whether the week numbers should use
> #. * localized digits or the ones used in English (0123...).
> #. *
> #. * Translate to "%Id" if you want to use localized digits, or
> #. * translate to "%d" otherwise.  Don't include the
> #. * "calendar:week:digits|" part in the translation.
> #. *
> #. * Note that translating this doesn't guarantee that you get localized
> #. * digits.  That needs support from your system and locale definition
> #. * too.
> #.
> #: ../gtk/gtkcalendar.c:1671 ../gtk/gtkcalendar.c:2089
> #, c-format
> msgid "calendar:week:digits|%d"
> 
> This doesn't work. If I translate to "%ld", msgfmt barfs and declares
> the PO file broken. 

You need a newer version of gettext.  1.14.1 is known to work, as well
as 1.15.0

behdad

> mathilde ~/i18n/gnome/HEAD/developer-libs/gtk+/po > msgfmt -cv nn.po
> nn.po:1176: format specifications in 'msgid' and 'msgstr' for argument 1 are 
> not the same
> msgfmt: found 1 fatal error
> 
> The solution, presumably, is to mark this msgid as not c-format or use
> strings like "LOCALIZED" and "UNLOCALIZED" instead.
> 
> Bug filed as #353981 in Bugzilla:
> http://bugzilla.gnome.org/show_bug.cgi?id=353981
> 
-- 
behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"

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

Re: Marking strings translatable in gucharmap

[Behdad Esfahbod]

On Fri, 2006-08-25 at 03:49 -0400, Wouter Bolsterlee wrote:
> På Thu, Aug 24, 2006 at 01:28:52PM -0400, Behdad Esfahbod skrev:
> > I want to fix a bug in gucharmap that causes two new strings ("Next
> > Block", "Previous Block") being marked for translation.  These strings
> > have been marked for translation before we switched to GtkUIManager
> > (about 9 months ago), so many translation files already have those
> > translated (grep suggests 33 out of 71 .po files contain them.)
> > 
> > http://bugzilla.gnome.org/show_bug.cgi?id=352665
> > 
> > May I?
> 
> The issue outlined above (strings already in the app, but not marked as
> translateable) are not affected by string freeze [1]... so I guess you
> should go ahead and do it NOW!
> 
>   mvrgr, Wouter
> 
> [1] Not marking those strings as such won't do any of us good, while marking
> them as such does not cause regressions.

Previously I've seen Danilo having concerns about marking new strings as
translatable as those change the statistics.  Anyway, after checking the
reference:

  http://live.gnome.org/TranslationProject/HandlingStringFreezes

I went on to commit the change, when I noticed that the bug reported has
committed it already.  Yay for everyone can write to everyone's
approach :-(.

-- 
behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"

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

Marking strings translatable in gucharmap

[Behdad Esfahbod]

I want to fix a bug in gucharmap that causes two new strings ("Next
Block", "Previous Block") being marked for translation.  These strings
have been marked for translation before we switched to GtkUIManager
(about 9 months ago), so many translation files already have those
translated (grep suggests 33 out of 71 .po files contain them.)

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

May I?

-- 
behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"

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

Re: Checking Translations (was: default text direction; mistranslations)

[Behdad Esfahbod]

On Wed, 2006-07-26 at 12:07 -0400, Shaun McCance wrote:
> On Wed, 2006-07-26 at 10:34 -0400, Matthias Clasen wrote:
> > gtk20.pot contains this comment, which explains how
> > to translate default:LTR.
> > 
> > #. Translate to default:RTL if you want your widgets
> > #. * to be RTL, otherwise translate to default:LTR.
> > #. * Do *not* translate it to "predefinito:LTR", if it
> > #. * it isn't default:LTR or default:RTL it will not work
> > #.
> > #: gtk/gtkmain.c:500
> > msgid "default:LTR"
> > 
> > but, running this little command
> > 
> > grep -A 1 "msgid \"default:LTR\"" *.po | grep msgstr | grep -v
> > "default:LTR" | grep -v "default:RTL"
> > 
> > yields a number of languages which have mistranslated that string:
> 
> Something I've been thinking about for a while is a system for
> checking translated strings.  Strings often have to conform to
> some syntax, whether it's selecting values from an enumeration,
> making a format string, writing well-formed XML, or whatever
> else.  In many of these cases, having incorrect translations
> can cause the program not to function correctly, or can break
> the build.

I raised this issue a few months ago.  I still suggest adding such tests
to the commit hook such that no broken PO file can be committed.  We
already msgfmt on commits; just need to add more elaborate checks.  With
the CVS migration, each project has its own commit hook file and can add
project-specific (like gtk+'s default:LTR) checks.

The original check I wrote was to detect broken glib context format
translation:

  http://mail.gnome.org/archives/gnome-i18n/2006-March/msg00246.html

In that, I go a bit out of my way to identify incorrect translations.
But now gettext 0.15 was released a few days ago

http://sourceforge.net/mailarchive/forum.php?thread_id=26741912&forum_id=7939

This includes various new features that Danilo and I suggested (and
builds better on win32 platforms thanks to our own Hans and Tor!).  If
we require gettext 0.15 after the SVN conversion and install 0.15 on our
servers, we can install a set of default checks and let projects extend
that to their desire.

New features of particular interest in GNOME in gettext 0.15 are:


 * xgettext's --keyword option now allows to specify an extracted
comment on the command line, rather than in program's source code. Now
we can automatically add a comment to all Q() strings (those with
context.)

 * msggrep has a new option -X/--extracted-comment that allows to search
for a pattern in the extracted comments. With this, you can match the
abovementioned comment with msggrep and double-check that the msgstr
doesn't have the '|' in it.

 * msggrep has a new option -v/--invert-match that acts like grep's -v
option.  With this you can write:

  msggrep -K -F -e 'default:LTR' |
  msggrep -T -E -v -e '^default:(LTR|RTL)$'

to essentially do what Matthias did, but with more accuracy.


Suggestions?

-- 
behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"

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

Re: Markup in messages

[Behdad Esfahbod]

> On 7/18/06, Christian Rose <[EMAIL PROTECTED]> wrote:
> > Behdad, this is about http://bugzilla.gnome.org/show_bug.cgi?id=347110
> > -- it was only recently that I discovered that you have included a
> > section about markup to http://live.gnome.org/GnomeI18nDeveloperTips :

Hi Chrisitan,

Actually Roozbeh added that.  I'm typically more relaxed as far as
future-proofing regulations goes :).

> > "Following is a list of examples that need to be marked for
> > translation, but were not in some cases:
> > [...]
> > '%s': That is an innocent way to mark something to make it
> > boldface in the interface, to emphasize importance or make it a
> > header. But not every language has a concept of modern boldface
> > typefaces, or even if it has such fonts, they may not be the preferred
> > font for such kind of emphasis."
> >
> > So are you suggesting that developers include the surrounding markup
> > in the translateable message, in case you may need to change it for
> > Persian for rendering purposes?

I'm almost sure there's no place in the Persian translations that we
make use of this.  And personally, I think your request is way to go.

> My guess is that they are just reluctant to changing anything
> not visually beneficial, not that they have already foreseen
> the problem. But to make an excuse, this is a good
> one, especially when what Behdad said is valid. I have been
> bitten by this kind of markup/font issues myself.
> 
> Due to absense of freely available boldface Chinese font, I
> have seen somebody translate things like:
> 
> msgid "%s"
> msgstr "%s"
> 
> in order to distinguish it from normal text.

This is the wrongest approach to solve this problem, and indeed what
Roozbeh has had in mind.  In the case of Chinese fonts with no bold
variant, there are a lot of possibilities on Linux.  First, with the
latest version of the text rendering stack, we should be emboldening for
you on the fly.  Second, if you want to replace bold with italic, you
can do that with a fontconfig configuration file.  There is a bug
against Pango to make artificial bold and italic faces even show in the
font selection widget.  That way, there's really no excuse to not use
bold faces (unless you are dealing with a bitmap font of course).

> Of course in most cases the proper 'fix' is to have a boldtype
> font. But creating a boldface font is not always that easy,
> when one is talking about complex scripts that consists of
> at least hundreds or thousands of glyphs; and it needs quite
> some human horsepower as well, which may not be available for
> newly available languages in F/OSS world.
> 
> Abel

-- 
behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"

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

String addition in gucharmap

[Behdad Esfahbod]

I marked the string "Snap Columns to Power of Two" for translation in
gucharmap.  Note that this string has been in the translation set for a
long time and accidentally dropped in Nov 2005.  So, most languages
already have it and don't need any further action.

-- 
behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"

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

Re: Fixing bug #330868 in a smart way

[Behdad Esfahbod]

On Mon, 2006-06-19 at 12:31 -0400, Christian Rose wrote:
> On 6/19/06, Paolo Maggi <[EMAIL PROTECTED]> wrote:
> > I was giving a look to bug #330868 (Adding "License" button and 
> > dialog
> > to About dialog). It seems to me we are duplicating the same long
> > strings (mostly the GPL license) in most applications marking them for
> > translation in order to add a "License" button to the about dialog.
> >
> > What about storing the most important open source licenses in a unique
> > repository in order to minimize string duplication and translators work?
> > I'm thinking to a special package like the one containing all the
> > languages name (the iso_639 module).
> 
> I would prefer if such functionality could be added to GTK+, at least
> for the short License declarations (like "This program is free
> software; you can redistribute it and/or
> modify it under the terms..."), for the following reasons:

I replied to this thread, but seems like it didn't make it through the
list.  I've been working on exactly what you suggest in this bug:

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

A couple of technical questions remain open, but you get the idea.

-- 
behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"

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

Re: Unicode Font Guide For Free/Libre Open Source Operating Systems

[Behdad Esfahbod]

On Tue, 18 Apr 2006, Simos Xenitellis wrote:

> O/H Behdad Esfahbod έγραψε:
> > Following up with recent discussion about fonts, I found this
> > invaluable:
> >
> >   http://www.unifont.org/fontguide/
> >
> The SOC would be a good opportunity to sort out the fonts and come up
> with candidate fonts.conf files that distributions can have.
> That is, which is the optimal selection of fonts for fontconfig but also
> for VCL.xcu (OpenOffice.org).
> It might be difficult to enforce, however having a somewhat common set
> of fonts will be good
> as documents and UIs would look somewhat similar.

While are free and encouraged to add your idea to the pool of
ideas, I doubt we will be accepting such a project for various
reasons, one of them being that SoC is about coding and for
example the FAQ says that writing documentation is not accepted.
Moreover, I don't think a SoC student has enough expertise to do
such font selection.

A really good SoC idea is to work on the fontmanager.


> Simos

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Unicode Font Guide For Free/Libre Open Source Operating Systems

[Behdad Esfahbod]

Following up with recent discussion about fonts, I found this
invaluable:

  http://www.unifont.org/fontguide/

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: vte branched for GNOME 2.14

[Behdad Esfahbod]

On Fri, 31 Mar 2006, Danilo Šegan wrote:

> Today at 2:38, Behdad Esfahbod wrote:
>
> > Vte has been branched for GNOME 2.14.  The branch name is
> > vte-0.12
>
> Thanks for the notice.  The branch name seems to actually be
> "vte-0-12", but is there any reason you didn't use "gnome-2-14" as is
> common for most modules (except glib and gtk+)?

Just Happened.  :)

> Also, there is already "gnome-2-2" branch in vte.
>
> Cheers,
> Danilo

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: vte branched for GNOME 2.14

[Behdad Esfahbod]

On Fri, 31 Mar 2006, Clytie Siddall wrote:

>
> On 31/03/2006, at 11:08 AM, Behdad Esfahbod wrote:
>
> > Vte has been branched for GNOME 2.14.  The branch name is
> > vte-0.12
>
> Behdad, this means vte will have its own separate branch, outside the
> gnome-2-14 directory, is that right?

I'm not sure what you exactly mean by gnome-2-14 directory, but
this is exactly like what gtk and glib are doing.  Just after
branching I regretted that I didn't name the branch gnome-2-14,
yes.

> This is more difficult to do, and to remember. Is it really necessary
> for some files to branch in this way?

Probably won't happen next time :)

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

vte branched for GNOME 2.14

[Behdad Esfahbod]

Hi,

Vte has been branched for GNOME 2.14.  The branch name is
vte-0.12

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Trying out GNOME 2.14 in a breeze

[Behdad Esfahbod]

On Fri, 17 Mar 2006, Alexander Shopov wrote:

> Yep - we all eat M4 for breakfast, we play incessantly Grand CONF Auto
> and generally write our drivers using cat. In binary.
> This is all it takes to be a translator.

Oh Yeah?!  I thought translators don't run GNOME apps, let alone
compiling it. :-P

But seriously, the easiest way to test those stuff is to tease
somebody like Luis to create a LiveCD with your language stuffed
in it.

> We are the lean and mean translator machine.
>
> Kind regards:
> al_shopov

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Trying out GNOME 2.14 in a breeze

[Behdad Esfahbod]

On Thu, 16 Mar 2006, [iso-8859-5] ��� [iso-8859-5] � wrote:

> Another suggestion:
>
> You could also get the latest dapper build or upgrade your existing
> ubuntu breezy. GNOME 2.14 is available with the latest dapper updates.

Yes, it is sane to assume that majority of translators run
Ubuntu.  And also to assume that majority of them are fine
dealing with technicalities of upgrading their distro to a
developmental version...

> -Arangel

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Simple tool to check for glib-style translation context format

[Behdad Esfahbod]

Hi,

I hacked up the attached script that can be used to check
translations for invalid translation of glib-style context
strings.  It's a simple heuristic, but does the job, and we can
extend it as more complex cases show up.

Questions:

1) I can already see the following have incorrect translations in
gtk+ HEAD: bn, br, cs, mk, ne, ru, sq, xh.  Can someone run this
on all current translations of all modules?  And shall we fix it
or let the translators do?  Seems like they don't...  I can hack
another script to automatically fixing them, by replacing their
msgstr with an empty string.  The command I used is this btw:

  for x in *.po; do check-glib-context $x >/dev/null || echo $x; done


2) Shall we write our own extended msgfmt in intltool?  In glib?


3) Ross, can you install this as part of the po/ commit script?


That's all for now I guess.

Cheers,

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"#!/bin/sh

cat "$@"|
grep -v "^# "   | # remove translator comments
sed 's/^#[.]/# /'   | # change automatic comments to translator comments
msggrep -K -F -e '|'| # grep messages with '|' in msgid
msggrep -T -F -e '|'| # grep messages with '|' in msgstr
msggrep -C -E -i -e '(before|prefix|strip).*[|]' \
| # grep messages with a comment like "strip before |"
if LANG=C grep .; then
exit 1
else
exit 0
fi
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Committing po-file changes, agian

[Behdad Esfahbod]

On Mon, 13 Mar 2006, Vincent Untz wrote:

> Le lundi 13 mars 2006 à 00:32 -0500, Behdad Esfahbod a écrit :
> > Hi Danilo and others,
> >
> > I did checkout and install latest intltool, and reran autogen and
> > build and all in vte, but still I get all translations modified
> > after a distcheck.
> >
> > I'm afraid I'm going to commit them this time too, but I'm
> > willing to fix this issue as soon as somebody here tells me how.
> > Same probably will happen with gucharmap in a few minutes.
>
> It seems vte doesn't use intltool. gucharmap does, though.

Ah, that's out of my autofoo expertise.  Anybody willing to
submit a patch?  I opened this bug for it:

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

> Vincent

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

gucharmap branched for GNOME 2.14

[Behdad Esfahbod]

The branch name is gnome-2-14.


--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Committing po-file changes, agian

[Behdad Esfahbod]

Hi Danilo and others,

I did checkout and install latest intltool, and reran autogen and
build and all in vte, but still I get all translations modified
after a distcheck.

I'm afraid I'm going to commit them this time too, but I'm
willing to fix this issue as soon as somebody here tells me how.
Same probably will happen with gucharmap in a few minutes.

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Fantasdic, ask for translations

[Behdad Esfahbod]

> Ruby is not just a prototyping language. At least, at the performances
> level, I don't see any reason why we should rewrite it in C. Python
> applications are not rewritten in C.

Nobody said that, but it's also true that official GNOME releases
are not going to depend on Ruby anytime soon.  We have just
recently decided to recognize Python apps as first class
citizens, and still have not let Mono in.  So, the C-based
dictionary utility is going to stay with us for a while anyway.
It's also a known fact that Ruby is higher level than C, and
easier to experiment with.


> That said, I want GNOME Dictionary to continue to live too. But
> Fantasdic in itself, as an application, has interesting features that
> may interest some people. That's not just a place to experiment for
> GNOME dictionary.

Definitely.  If it didn't, it would not have been let in in the
first place :).

> Also, I would like to thank the account team for accepting my project.

You are welcome.


--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Fonts for distribution

[Behdad Esfahbod]

On Thu, 9 Mar 2006, Clytie Siddall wrote:

> I don't know how useful it is to compare Linux with Mac OSX (UNIX),

Absolutely useless in this case.

> but I use Lucida Grande all the time _because_ it covers such a wide
> range of characters. Not having to change font when I change
> languages is a major convenience, even though changing font is only a
> couple of keystrokes or clicks in OSX.

Yes, but in GNOME (and Firefox) you don't have to change font.
The software picks the best font for each script automatically.

Now if you install fonts that cover a wide range of scripts, but
do a poor job for most of them, then you are in trouble and have
to change fonts all the time, to get rid of the ugly
general-purpose font.

In other words, let programmers think about font handling and
users enjoy the software.  If you have fonts you want to see
distributed, file feature requests for them with major distros,
but trying to push glyphs for your favorite into wide-spread
fonts is a recipe for disaster.  Please don't do that, for the
same reason that I do not commit Vietnamese translations.

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Fantasdic, ask for translations

[Behdad Esfahbod]

On Thu, 9 Mar 2006, Danilo Šegan wrote:

> Today at 0:12, Mathieu Blondel wrote:
>
> > The same way you can use a browser to navigate through pages provided
> > by an HTTP server, you can use Fansdic (the client) to query
> > dictionaries provided by a DICT server.
>
> It seems to complement what gnome-utils/gnome-dictionary already does?
> (gnome-dictionary is a DICT client itself)
>
> In what ways does it differ?

Part of the reason that this project was accepted to be hosted in
GNOME CVS was that it's written in Ruby, and we don't have many
Ruby applications at home.  So I think having Fantasdic helps our
Ruby bindings, as well as a gnome-dictionary dup written in a
higher level language that can more easily experiment new
features, that we may want to add to gnome-dictionary later...

> — Danilo

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Fonts for distribution

[Behdad Esfahbod]

On Thu, 9 Mar 2006, Simos Xenitellis wrote:

> There is a similar discussion going on at the dejavu-devel mailing list.
> There is interest from contributors to add glyphs for more languages,
> like Arabic and CJK, as it has been with FreeFont which supports with
> different levels of quality Latin, Central European, Cyrillic, Greek,
> Arabic, CJK and perhaps more.

Then please ask them to release DejaVuArabic, DejaVuCyrrillic,
etc.

> The issue arises from the fact that to use such a wide-coverage Unicode
> fonts, one has to add high on the preference list
> at /etc/fonts/fonts.conf
> However, by doing so, other fonts are masked (hidden), such as Arabic
> and CJK (Kochi).

There are several issues.  Most fonts that cover multiple
scripts, have ugly glyphs for all but one or two of them.  Or
they may simply not be my favorite ones.  And remember that
beautiful fonts for Arabic are among the ugliest for Persian.
Listing defects really doesn't make much sense.  It's like
bundling all GNOME apps together, saying you can either use all
of these, or none of them.

> Therefore, we have the interest of individual contributors to have their
> script added or new fonts submitted that have partial support for some
> scripts (for example, SIL Doulos has partial Greek support).
> What is the best solution to solve this issue?

fontconfig configuration.  Fontconfig knows about languages, so
if SIL Doulos has partial Greek support, fontconfig doesn't mark
it as supporting Greek, and so when some text is marked as Greek,
SIL Doulos will not be used to render that...  This support is
not perfect in the stack, but definitely improving.

> Or, should fontconfig be enhanced so that it allows a new configuration
> option to mask/hide character ranges on specific fonts?
> For the latter, there is a bug report waiting for developer love, at
> https://bugs.freedesktop.org/show_bug.cgi?id=5987

No, I don't think that bug is going to be resolved any time soon.
As I said above, it's supposed to be already handled in another
way.

> Simos

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Fonts for distribution

[Behdad Esfahbod]

On Thu, 9 Mar 2006, Clytie Siddall wrote:

> so he might well be willing to incorporate the glyphs for your
> language. :)

Making fonts that have glyphs for multiple scripts is in fact not
recommended in Linux.  Having separate fonts for different
scripts have various benefits.  Simply, don't do that.


--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: kn.po breaking build in vte

[Behdad Esfahbod]

On Wed, 8 Mar 2006, Abel Cheung wrote:

> On 3/9/06, Behdad Esfahbod <[EMAIL PROTECTED]> wrote:
> >
> > The 'kn.po' that you added to configure.in in vte was breaking
> > build badly, and so removed.  Don't you ever msgfmt translations
> > before hooking them up?
>
> Strange, I am pretty sure I did found something wrong with kn.po
> and then commit every changed files. Anyway, I'll try to fix it by
> marking the wrong place as fuzzy and email translator, because
> the kannada translation is not actively maintained (last updated
> 2003).

It would also help if you update the metadata at the beginning of
the file to list who the translator is and other stuff.  If
translations have not been updated since 2003, maybe we should
disable them and wait for somebody to step up...


> Abel
>
>
> >
> > --behdad
> > http://behdad.org/
> >
> > "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
> > -- Dan Bern, "New American Language"
> > ___
> > gnome-i18n mailing list
> > gnome-i18n@gnome.org
> > http://mail.gnome.org/mailman/listinfo/gnome-i18n
> >
>
>
> --
> Abel Cheung   (GPG Key: 0xC67186FF)
> Key fingerprint: 671C C7AE EFB5 110C D6D1  41EE 4152 E1F1 C671 86FF
> 
> * GNOME Hong Kong - http://www.gnome.hk/
> * Opensource Application Knowledge Assoc. - http://oaka.org/
>

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: cvs-commits-list reports messed up?

[Behdad Esfahbod]

On Wed, 8 Mar 2006, Danilo Šegan wrote:

> Yesterday at 22:35, Behdad Esfahbod wrote:
>
> > Thinking again, I removed the LINGUAS line, so I do check all
> > translations for possible build problems.  So I'm not making any
> > exceptions for 'fa' anymore.  That means, upon each release, I'm
> > going to commit line-number changes to all languages.  This has
> > been the tradition in all projects AFAIK.
>
> Tradition we are changing!  Look for removing update-po rule from
> "make distcheck" discussions.  For example, the one dated May 2003:
>
>   http://mail.gnome.org/archives/gnome-i18n/2003-May/msg00174.html
>
> Rodney has removed "update-po" dependency from intltool as well:
>
>   http://mail.gnome.org/archives/gnome-i18n/2005-January/msg00136.html
>
>
> Please, don't commit any changes to PO files if you can avoid it.

That's what I said.  I will install intltool HEAD.


> Cheers,
> Danilo

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

kn.po breaking build in vte

[Behdad Esfahbod]

Hello,

The 'kn.po' that you added to configure.in in vte was breaking
build badly, and so removed.  Don't you ever msgfmt translations
before hooking them up?

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: cvs-commits-list reports messed up?

[Behdad Esfahbod]

On Wed, 8 Mar 2006, Behdad Esfahbod wrote:

> There has been a long discussion about this on various lists
> before.  Unless the problem is solved in the build system or
> another way, I cannot guarantee I don't do that in the future.
> That means I should never ever do 'cvs ci' and have a modified
> source tree all the time.  On the other hand, I can argue that
> it's not unnecessary.  The fact that it doesn't have new
> translation is confirmed by the fact that there's no ChangeLog
> entry for it.  The source code has changed, and the line numbers
> change.

Also note that the commit is necessary to make sure what goes in
the tarball is what is in the CVS when we tag the cvs for
release.

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: cvs-commits-list reports messed up?

[Behdad Esfahbod]

Thinking again, I removed the LINGUAS line, so I do check all
translations for possible build problems.  So I'm not making any
exceptions for 'fa' anymore.  That means, upon each release, I'm
going to commit line-number changes to all languages.  This has
been the tradition in all projects AFAIK.

behdad

On Wed, 8 Mar 2006, Behdad Esfahbod wrote:

> On Wed, 8 Mar 2006, Roozbeh Pournader wrote:
>
> > روز چهارشنبه، 2006-03-08 ساعت 15:15 -0500، Behdad Esfahbod نوشت:
> >
> > > To hide the problem, I have export LINGUAS="en fa" in my bash
> > > profile, so only fa.po is regenerated in my checkouts.
> >
> > I would appreciate it if you don't commit unnecessary changes to fa.po
> > then.
>
> There has been a long discussion about this on various lists
> before.  Unless the problem is solved in the build system or
> another way, I cannot guarantee I don't do that in the future.
> That means I should never ever do 'cvs ci' and have a modified
> source tree all the time.  On the other hand, I can argue that
> it's not unnecessary.  The fact that it doesn't have new
> translation is confirmed by the fact that there's no ChangeLog
> entry for it.  The source code has changed, and the line numbers
> change.
>
> And no, removing 'fa' from LINGUAS is not an option either.  I
> want to have at least one language in there to test the build
> process.  That better be one that I can actually read and
> understand, as I regularly test running apps I maintain under
> fa_IR and check that all the strings are marked for translation,
> etc.
>
> If you never noticed this before, means it's not making any
> problem.  So I don't see a real reason not to continue that.
>
>
> > roozbeh
>
> --behdad
> http://behdad.org/
>
> "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
>   -- Dan Bern, "New American Language"
>

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: cvs-commits-list reports messed up?

[Behdad Esfahbod]

On Wed, 8 Mar 2006, Roozbeh Pournader wrote:

> روز چهارشنبه، 2006-03-08 ساعت 15:15 -0500، Behdad Esfahbod نوشت:
>
> > To hide the problem, I have export LINGUAS="en fa" in my bash
> > profile, so only fa.po is regenerated in my checkouts.
>
> I would appreciate it if you don't commit unnecessary changes to fa.po
> then.

There has been a long discussion about this on various lists
before.  Unless the problem is solved in the build system or
another way, I cannot guarantee I don't do that in the future.
That means I should never ever do 'cvs ci' and have a modified
source tree all the time.  On the other hand, I can argue that
it's not unnecessary.  The fact that it doesn't have new
translation is confirmed by the fact that there's no ChangeLog
entry for it.  The source code has changed, and the line numbers
change.

And no, removing 'fa' from LINGUAS is not an option either.  I
want to have at least one language in there to test the build
process.  That better be one that I can actually read and
understand, as I regularly test running apps I maintain under
fa_IR and check that all the strings are marked for translation,
etc.

If you never noticed this before, means it's not making any
problem.  So I don't see a real reason not to continue that.


> roozbeh

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: cvs-commits-list reports messed up?

[Behdad Esfahbod]

On Tue, 7 Mar 2006, Roozbeh Pournader wrote:

> روز سه‌شنبه، 2006-03-07 ساعت 21:42 -0500، Behdad Esfahbod نوشت:
> > Seems like the commits script is messing up a bit.  See this one
> > for example, my commit on vte has been mixed with a translators
> > in straw:
> >
> >   
> > http://mail.gnome.org/archives/cvs-commits-list/2006-February/msg06319.html
> >
> > Sorry if it's old news,
>
> Bonsai also returns weird results:
> http://cvs.gnome.org/bonsai/cvsquery.cgi?branch=&dir=vte&who=behdad&date=explicit&mindate=2006-02-25%2019:12&maxdate=2006-02-25%2019:14
>
> (Check the change in fa.po)

The fa.po is actually correct.  Whenever source code changes such
that the line numbers of translatable messages are affected, upon
certain activities (make distcheck?), a new pot-file is generated
and so merged with translations before making them.  This is
quite a known problem, mostly affecting the less technical
translators that do not merge from CVS.

To hide the problem, I have export LINGUAS="en fa" in my bash
profile, so only fa.po is regenerated in my checkouts.

> roozbeh

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

cvs-commits-list reports messed up?

[Behdad Esfahbod]

Hi,

Seems like the commits script is messing up a bit.  See this one
for example, my commit on vte has been mixed with a translators
in straw:

  http://mail.gnome.org/archives/cvs-commits-list/2006-February/msg06319.html

Sorry if it's old news,

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: string freeze confusion

[Behdad Esfahbod]

On Fri, 3 Mar 2006, Roozbeh Pournader wrote:

> روز پنجشنبه، 2006-03-02 ساعت 20:10 -0500، Behdad Esfahbod نوشت:
> > Nobody knows that
> > something like this needs to be marked for translation, because
> > there's no rule saying so anywhere.
>
> You're right of course, but I am coming to the belief that everything
> that is displayed to a normal user (vs written in logs, only saved in
> config files, sent on the wire using the various protocols, etc) should
> be marked for translation. "%d" and "%f" need to be marked for
> translation (for users of localized digits), "," (comma) needs to be
> marked for translation (for Arabic script languages), "%s" needs
> to be marked for translation (for locales that don't use boldface or
> prefer not to), "%s <%s>" needs to be translated (for bidi
> languages), ...

Just put these all in:

  http://live.gnome.org/GnomeI18nDeveloperTips

or a separate page linked from there.

> > The point being: this really needs to
> > be documented somehwere.  So no, it's not ignorance.  It's lack
> > of docuentation.
>
> I can't agree more.
>
> roozbeh

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: string freeze confusion

[Behdad Esfahbod]

On Fri, 3 Mar 2006, Roozbeh Pournader wrote:

> روز پنجشنبه، 2006-03-02 ساعت 21:20 -0500، Behdad Esfahbod نوشت:
> > Roozbeh, do you mind drafting
> > something about this on the wiki?
>
> Sure, but I don't really know my way around the wiki. Isn't the
> documentation for this stuff (developer's howto for i18n) on
> developer.gnome.org?

Just put it somewhere so it's not lost and link it from:

  http://live.gnome.org/GnomeI18nDeveloperTips

and we can always move it later.

> Roozbeh

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: Fonts for distribution

[Behdad Esfahbod]

On Tue, 7 Mar 2006, Erdal Ronahi wrote:

> Hi,
>
> are there any free fonts out there that are known to support the variants of
> Arabic script well? We have particular problems with Kurdish which has some
> diacritics not used in other languages. There are a lot of fonts for
> standard arabic script, but less for variants. I could not find any suitable
> font in Ubuntu, and I think this is an issure for GNOME also.

Did you try SIL.org fonts?

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

Re: release notes: first draft

[Behdad Esfahbod]

Oops.  Forgot to CC lists.

On Tue, 7 Mar 2006, Behdad Esfahbod wrote:

>
> Neat job.
>
>
> In front page:
>
> "free software" => "Free Software"
>
>
> Users -> Performance:
>
> "font rendering" => "text rendering" (we did not optimizing the
> actual drawing at all, just the text layout...)
>
> "the entire dictionary" => "an entire English word list" / "an
> entire dictionary"
>
>
> Developers:
>
> "Developer's Platform" => "Developers' Platform"
>
>
> Cheers,
> behdad
>
> On Mon, 6 Mar 2006, Davyd Madeley wrote:
>
> > Ok guys and gals. I am announcing a preliminary draft of the release
> > notes for 2.14. We now require proof readers for spelling, grammar and
> > technical correctness.
> >
> > The latest committed version is online at:
> > http://www.gnome.org/start/2.14/notes/C/index.html
> >
> > You can also check out the release notes from CVS:
> > http://cvs.gnome.org/viewcvs/gnomeweb-wml/www.gnome.org/start/2.14/notes/docbook/C/
> >
> > We are using gnome-doc-utils for translation. I hope the translators
> > know how to get all of that working, because I have no idea.
> >
> > Warning, I AM AN AUSTRALIAN, SPELLINGS MAY BE CONSIDERED INCORRECT. My
> > grammar is also pretty appalling. Please send through corrections for
> > these. Feel free to correct minor spelling mistakes yourself.
> >
> > Discussion should happen on list as appropriate or on the IRC channel
> > #release-notes on irc.gnome.org.
> >
> > Addendum:
> >  - If anyone knows the status of the LiveCD, that section requires
> > updating.
> >  - Danilo was meant to be providing the i18n stats page, he said he
> > added it, but I can't see where.
> >  - Does anyone want to take charge on writing a press release? I am
> > willing to raise my hand again if so required.
> >
> >
>
> --behdad
> http://behdad.org/
>
> "Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
>   -- Dan Bern, "New American Language"
>

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

String change in dasher

[Behdad Esfahbod]

Hi,

This is to inform that a couple new strings has been marked for
translation in dasher (gnome-2-14 branch too) that have not been
marked so accidentally.

See bug #333518 for details.

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: string freeze confusion

[Behdad Esfahbod]

On Thu, 2 Mar 2006, Danilo Šegan wrote:

> Today at 2:10, Behdad Esfahbod wrote:
>
> > On Thu, 2 Mar 2006, Andre Klapper wrote:
> >
> >> hmm. ok. after reading the bug report, i guess it's time to find a
> >> useful and clear definition of "by accident", i guess.
> >
> > Accident is clear enough IMHO.  It's something that obviously
> > should have been marked for translation, but is not.
>
> Now we are getting the problem of defining "obvious".  Was it obvious
> that this string should have been marked or not? :)

I covered that in the next paragraph ;).  No, it's not obvious.
Go ask 10 GNOME devs, 9 will tell you not...  Those who think it
should be marked for translation probably don't know about the
localized digits thing either.  Roozbeh, do you mind drafting
something about this on the wiki?

> We've got the same problem. :)
>
> Cheers,
> Danilo

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

Re: string freeze confusion

[Behdad Esfahbod]

On Thu, 2 Mar 2006, Andre Klapper wrote:

> hmm. ok. after reading the bug report, i guess it's time to find a
> useful and clear definition of "by accident", i guess.

Accident is clear enough IMHO.  It's something that obviously
should have been marked for translation, but is not.

> i guess the message was not marked for translation because the developer
> did not expect a language to exist that needed to change the string "%s
> (%u)". so... "is ignorance also an accident?" :-)

There's the problem.  It's not really ignorance if somebody
didn't mark "%s (%u)" for translation.  Nobody knows that
something like this needs to be marked for translation, because
there's no rule saying so anywhere.  It was us (Roozbeh and I
basically) that decided we are going to ask all apps to mark
their format strings for translation whenever we need to use
Persian digits somewhere.  The point being: this really needs to
be documented somehwere.  So no, it's not ignorance.  It's lack
of docuentation.

> andre :-/

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n

String change in gucharmap

[Behdad Esfahbod]

On Mon, 20 Feb 2006, Danilo Šegan wrote:

> Hi Behdad,
>
> Yesterday at 23:10, Behdad Esfahbod wrote:
>
> > As a result of the UI review that was help on Thursday, we would
> > like to change this string in gucharmap:
> >
> >   "based on Unicode Character Database"
> >
> > to
> >
> >   "based on the Unicode Character Database"
> >
> > I will also patch all PO files, so no action is requried from the
> > translators.  May I do this?  (Note the string change was
> > committed to CVS and reverted after a few hours.)
>
> Go ahead, but please notify translators using gnome-i18n when you
> start, and when you finish this process (to avoid CVS conflicts, if
> possible).

Ok translators.  The above change was committed to CVS right now.
The process didn't take more than five minutes...

behdad


> Cheers,
> Danilo

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
-- Dan Bern, "New American Language"
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n