Re: Translating schema files (was: Re: Survey results (yay!))

Op Ma, 2010-11-01 om 20:26 +0100 skryf Ask Hjorth Larsen:
> On Mon, Nov 1, 2010 at 7:32 PM, Gil Forcada <gforcada gnome org> wrote:
> > El dl 01 de 11 de 2010 a les 18:35 +0100, en/na Jorge González González
> > va escriure:
> >> El lun, 01-11-2010 a las 19:29 +0200, Ihar Hrachyshka escribió:
> >>
> >> > You're wrong when speaking about "normal user". Normal user:
> >> > 1) either use Google or NOT for searching problem solutions;
> >> > 2) should be able to fix the problem with no external help (google,
> >> > friends, tech support). If not, then the software is wrong, the error
> >> > messages are wrong, but the errors localisation is ok.
> >> Well, obviously we don't deal with the same "normal users".
> >>
> >> >
> >> > So though I'm for separating schema messages, I'm against separating
> >> > errors from UI messages.
> >> I'm against separating them since it will include more files to push and
> >> handle, but I'm against translating them at all.
> >
> > My first idea was to split to different files, but Simo's approach was
> > about giving D-L the ability to show different filtered files from the
> > same file (and only one po file in git).
> >
> > So you then would be able to either translate everything (errors,
> > schemas and "ui") or just some parts (first only the ui, then the errors
> > and finishing with the schemas).
> >
> > That way keeping only a single file for each module but showing them as
> > a separate files small teams and new contributors would feel that their
> > translations make sense from the very beginning.
> >
> > Then the question is how to create this filters and implementing them in
> > D-L.
> >
> > Anyone is up to this?

I would be interested in helping with this. It would serve as a great
encouragement for small teams like mine, I believe.

> But how would you reliably distinguish between error messages and
> non-error messages?  I'm not convinced that this can be done without
> requiring unreasonable work from programmers.

I think we should start with something we know is doable: handling the
schema entries.  If we want to do more, we can look for ways of doing it
automatically, even if it doesn't eliminate all error messages or
command line options, for example.  But eliminating just the schema
messages, saves us 17% of a very big number, and also has many other
benefits as explained elsewhere in the thread.


Recently on my blog:

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]