[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: [RFC] Future of msgsplit
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2006-01-16 7:54:30
Message-ID: 200601160854.30198.nicolasg () snafu ! de
[Download RAW message or body]

On Tuesday 10 January 2006 18:35, Nicolas Goutte wrote:
> On Monday 09 January 2006 21:46, Gaute Hvoslef Kvalnes wrote:
> > På Mon, 09 Jan 2006 21:28:50 +0100, skrev Thomas Reitelbach
> >
> > <tr@erdfunkstelle.de>:
> > > On Thursday 05 January 2006 17:39, Nicolas Goutte wrote:
> > >> One the other side, nearly no team is using it.
> > >
> > > Maybe because they don't know about it like me. How are we expected to
> > > "use" it?
> >
> > Since Scripty uses it, I'd say that every team indirectly uses msgsplit.
>
> No! What counts are the commits from the teams. And really very few team
> use msgsplit.
>
> > >> Asumming that a complete drop of msgsplit is not wanted, then we have
> > >> to talk about each of its features and see which one are wanted
> > >> (splitting at
> > >> tags or at certain (European) sentence separators) or which ones are
> > >> not (wrap at 80 characters instead of 78).
> > >
> > > What _are_ the features of it?
> > > In what way do we (translators) benefit from it?
> > > As no one else replied up to now, we might first discuss about what
> > > msgsplit is and what it's all about.
> >
> > I believe the main purpose was to wrap long strings to avoid horizontal
> > scrolling in KBabel. Now, KBabel has supported soft wrapping for a while,
> > so this is not as important anymore.
>
> But the output format of the Gettext tools offer that too. So that is not
> an argument in favour of msgsplit.
>
> > Another feature of msgsplit is the nice wrapping of HTML-formatted
> > strings. I believe this is still very useful. Compare the two following
> > strings. The second one is processed by msgsplit, and much easier to read
> > and translate:
> >
> > msgid "Although contact was made with the server, a response was not
> > received within the amount of time allocated for the request as
> > follows:<ul><li>Timeout for establishing a connection: %1
> > seconds</li><li>Timeout for receiving a response: %2
> > seconds</li><li>Timeout for accessing proxy servers: %3
> > seconds</li></ul>"
>
> To be picky: as this is a multiline string, Gettext would start with msgid
> "" too.
>
> However mgsplit does it also with single line strings. So you have files
> that have two times more lines than necessary, increasing the rik of
> conflicts.
>
> Also in future the context is a new keyword (mgctxt), so it means that with
> msgsplit, it gives one more line (instead of being neutral in the number of
> lines).
>
> > msgid ""
> > "Although contact was made with the server, a response was not received
> > within "
> > "the amount of time allocated for the request as follows:"
> > "<ul>"
> > "<li>Timeout for establishing a connection: %1 seconds</li>"
> > "<li>Timeout for receiving a response: %2 seconds</li>"
> > "<li>Timeout for accessing proxy servers: %3 seconds</li></ul>"
>
> But should this not be more a feature of the used GUI tool? (Sure, KBabel
> can probably not do it currently.)

I had written that answer rather quickly but thinking of it, this is the core 
problem. So I suppose that msgsplit needs to be kept for KDE 4.0 and we will 
need to see what will be done in KBabel for KDE 4.0, to be able to drop it in 
KDE 4.1.

As for the details about the difference about Gettext, msgsplit and KBabel, I 
ahve realized that I should check better what KBabel does, before starting 
again this discussion on this mailing list.

>
> > (From Gettext's point of view, these strings are identical.)
>
> Have a nice day!
>
> > Regards,
> >   Gaute Hvoslef Kvalnes

Have a nice day!


[prev in list] [next in list] [prev in thread] [next in thread]