Re: Missing file in libxklavier CVS
- From: Jody Goldberg <jody gnome org>
- To: "Sergey V. Oudaltsov" <sergey oudaltsov clients ie>
- Cc: gnome-i18n gnome org
- Subject: Re: Missing file in libxklavier CVS
- Date: Mon, 10 Nov 2003 12:32:27 -0500
On Mon, Nov 10, 2003 at 03:56:43PM +0000, Sergey V. Oudaltsov wrote:
> > My thought was that because intltool nicely splits the translations
> > out into po files then remerges things it would be very easy to
> > generate patches that could be fed upstream.
> This is exactly how the "right" version of xfree86.xml is prepared! But
> will GTP support two branches in CVS: HEAD and 4.2?
Can't we avoid having two branches and just use HEAD ? My hope
would be that libxklavier could filter elements that the server does
not know about. We've already playing fast and loose with using the
same file for and xserver that does not include it. It seems easier
to just use HEAD, and avoid branching at all. That will make
> > These are user visible strings in an area that intl users are fairly
> > likely to look. Proper translation is a very high priority.
> "Fairly likely" is not statistics.
I don't claim it is. Those are strings that people will see. For
2.6 we will need translation coverage on par with the rest of the
core gnome desktop.
> Where would be the turn point when we
> could consider 4.2 as obsolete? New Debian stable with 4.3?
This is an unrelated point. I suspect we won't. The only other
option would be to notice it is missing and disable the layout ui
entirely as if xkb was missing.
> > We could put the actual upstream version in GNOME CVS. Fantastic.
> > That would make would ideal from a translation perspective.
> Only for the file shipped with XFree!:) So, should I consider this
> comment as "go ahead" for creating new module in GNOME CVS? I am ready
> at any point.
It's fine by me. Put the fine in the gswitch-common module and mark
it for translation. I'll contact the release and translation folk
to get it on the lists.
> > I just want to put it there - and
> > > forget:)
> > Why not keep the fallback in sync, even if it is only updating it at
> > release time as you do now ?
> Because it would require my special attention during the release
> procedure - not to forget to update it. I want it either to be in CVS -
> and be virtually "read-only, no maintenance" thing - or not to be in CVS
> - and be a symlink (on my system) to the _actual_ and _up-to-date_
You could set up a cron job on your machine to update it.
or add some wget magic to the dist process to update it.
Neither should be terribly taxing.
] [Thread Prev