Epiphany/Galeon dialog localization

[Christian Rose <menthos gnome org>]

tis 2003-05-20 klockan 15.11 skrev David Adam Bordoley:
> >> Personally I do appreciate Epiphany's cleanliness a lot, but there are
> >> some things from Galeon that I really use (cookie blocking and image
> >> blocking being the two big ones).  I can block cookies right now using
> >> Epiphany, but I get the abysmally ugly Mozilla XUL dialog for it.
> > 
> > Then that would be a bug rather than a missing feature. 
>
> Its not even a bug, you just need mozilla 1.4a (or maybe its b don't 
> remember) to get gtk prompts. We removed our own prompts implementation now 
> that gtkmozemebed provides wrappers for all the moz dialogs (although this 
> creates som i18n problems and we are talking with menthos about it, but 
> those we're always there even before we removed the prompt implementation). 

Yeah, this problem is quite severe from a GNOME L10N point of view, and
we've discussed this extensively without arriving at a satisfying
solution.

The basic problem is that Mozilla translations are severely lacking.
There exists Mozilla translations for far fewer languages than there are
translations for GNOME, and the Mozilla translations that exist are also
in most cases very incomplete and lagging behind the Mozilla development
by several releases. This has been the case from the very beginning of
the Mozilla project, and seems unlikely to change anytime soon, as the
reasons for this are probably both a combination of the L10N
implementation they chose to use, and many other factors.

So when Epiphany and Galeon display Mozilla dialog information, even if
the dialog itself can now be native instead of a XUL one, the dialog
message content is in many cases directly provided by Mozilla, and will
hence often be untranslated, while the rest of GNOME may not be. So the
effect is untranslated user-visible messages that we cannot do much
about.

The proper solution would be to either 1) fix Mozilla translations,
which is unlikely to happen anytime soon given the above, or 2) rewrite
the entire Mozilla dialog API so that embedding applications can
substitute dialog message content with their own, which of course also
is unlikely to happen anytime soon.

This is probably also a problem from a usability/HIG point of view, as
it's not possible to change the terminology (if needed) or the textual
formatting of such dialogs. In order to fix such things, we would need
2).


Christian