the gettext schemas translations are not being used

sample of actual results(screenshot).

expected results.

Thank you for your bug report, could you run gconftool --get /apps/gedit-2/preferences/encodings/auto_detected and copy that to the bug? The schemas translation use gettext in ubuntu that's why they are not in the xml but the translation are there

$ gconftool --get /apps/gedit-2/preferences/encodings/auto_detected

returns

[UTF-8,CURRENT,ISO-8859-15,UTF-16]

do you have language-pack-gnome-ja installed?

Yes.

$ LANG=C apt-cache policy language-pack-gnome-ja-base

language-pack-gnome-ja-base:
  Installed: 1:9.10+20090930
  Candidate: 1:9.10+20090930
  Version table:
 *** 1:9.10+20090930 0
        500 http://jp.archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

language-pack-gnome-ja also installed.
gedit.mo is content of language-pack-gnome-ja-base

Hmm, my translations don't seem to be working at all at the moment.
Default values are definitely not being translated, the gettext calls come from 02_xml-gettext-domain.patch, the following function needs to be fixed:
gconf/gconf-schemas.c:
GConfValue*
gconf_schema_get_default_value (const GConfSchema *schema)
{
  g_return_val_if_fail (schema != NULL, NULL);

  return REAL_SCHEMA (schema)->default_value;
}

Pushed these changes to lp:~robert-ancell/gconf/bug-443133 but testing doesn't seem to show this has fixed the problem. The test case I am running is:
 LC_ALL=ja_JP.UTF-8 LANG=ja_JP.UTF-8 gconftool --get /apps/gedit-2/preferences/encodings/auto_detected
which should return
"[UTF-8,CURRENT,CP932,SHIFT_JIS,ISO-2022-JP,EUC-JP-MS,EUC-JP,ISO-8859-15,UTF-16]"
not
"[UTF-8,CURRENT,ISO-8859-15,UTF-16]"

the change doesn't seem to do the trick indeed

I've been looking to the issue again today:

$ grep gettext /var/lib/gconf/defaults/* | wc -l
2829

$ sudo gconf-schemas --register gnome-screenshot.schemas

$ grep gettext /var/lib/gconf/defaults/* | wc -l
6

$ sudo gconf-schemas --register-all

$ grep gettext /var/lib/gconf/defaults/* | wc -l
2829

The gettext attribute is being cleaned when registering a schema (gconf-schemas is a wrapper to register schemas used after the installation) which explains why the descriptions are not translated. When the gettext attribute are there the descriptions are translated correctly but still not the default schemas value (using the karmic version on Robert's update)

running "sudo GCONF_CONFIG_SOURCE=xml:readwrite:/var/lib/gconf/defaults gconftool-2 --makefile-install-rule /usr/share/gconf/schemas/gnome-screenshot.schemas" has the same effect so it's not a wrapper issue

I've uploaded a version which should fix the gettext_domain attribute cleaning:

 gconf (2.28.0-0ubuntu2) karmic; urgency=low
 .
   * debian/patches/02_xml-gettext-domain.patch:
     - updated to not clear the gettext_attribute for the keys not
       being registered by the current schemas

it will not add those cleaned so running gconf-schemas --register-all one is required

Perhaps this should be done on upgrades of gconf?

I have upgraded gconf2 to 2.28.0-0ubuntu2.
And executed the line
$ sudo gconf-schemas --register-all

But
$ gconftool --get /apps/gedit-2/preferences/encodings/auto_detected
still returns
[UTF-8,CURRENT,ISO-8859-15,UTF-16].
It should be [UTF-8,CURRENT,EUC-JP-MS,CP932,EUC-JP,SHIFT_JIS,ISO-2022-JP,ISO-8859-15,UTF-16].

I have tried daily-live 20091008 clean-install with gconf2 2.28.0-0ubuntu2,
but it also returns [UTF-8,CURRENT,ISO-8859-15,UTF-16].

So I do not think this problem was fixed.

Indeed I think the problem of #12 was fixed.

I have found a strange point.

$ sudo GCONF_CONFIG_SOURCE=xml:readwrite:/var/lib/gconf/defaults gconftool-2 --makefile-install-rule /usr/share/gconf/schemas/gedit.schemas | grep auto_detected

returns

Attached schema `/schemas/apps/gedit-2/preferences/encodings/auto_detected' to key `/apps/gedit-2/preferences/encodings/auto_detected'
Installed schema `/schemas/apps/gedit-2/preferences/encodings/auto_detected' for locale `C'
in Japanese.

But it should be locale `ja' not `C'?

> So I do not think this problem was fixed.

that's why the bug didn't get closed, did you read previous comment? "When the gettext attribute are there the descriptions are translated correctly but still not the default schemas value (using the karmic version on Robert's update)"

> But it should be locale `ja' not `C'?

No, the C schemas is used and the translation should be get over gettext

The gconf part is fixed, the remaining one is too much schemas stripping in cdbs during the builds

gettext is not being used for the default values to avoid loading extra files

This bug was fixed in the package cdbs - 0.4.59ubuntu3

---------------
cdbs (0.4.59ubuntu3) karmic; urgency=low

  * Do not strip locale specific default values from gconf schema files:
    - Add strip-schema.pl: Replacement for the previous seddery, which wasn't
      powerful enough to just remove <short>/<long> tags from non-C <locale>
      tags, but keep <default> values.
    - Makefile.am: Install strip-schema.pl into pkglibdir.
    - 1/rules/langpack.mk.in: Drop seddery, use strip-schema.pl instead.
    - LP: #443133

 -- Martin Pitt <email address hidden> Thu, 08 Oct 2009 19:12:51 +0200

Sebastien, I apologize you for my behavior on #16 and #17.
I did not read carefully and could not understand your comment because of my poor English ability and techniqual knowledge.
So I misread the situation.

Now released gconf and cdbs which versions supposed to fix this bug, but cdbs is a build tool.
When does this fix take effect for gedit auto-detecting failure?
Is it when updates of gedit or language-pack-gnome-ja-base are released?
Sorry in advance if I'm writing wrong things.

Nobuto MURATA [2009-10-09 19:07 -0000]:
> Now released gconf and cdbs which versions supposed to fix this bug, but cdbs is a build tool.
> When does this fix take effect for gedit auto-detecting failure?

A new GNOME point release is due next Monday, during which a lot of
the GNOME packages will be rebuilt, and get this fixed. The remaining
ones which have locale specific defaults shouldn't be many, and we can
easily do no-change uploads to get them rebuilt.

Martin