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

List:       kde-i18n-doc
Subject:    Re: lokalize GSoC application
From:       Chusslove Illich <caslav.ilic () gmx ! net>
Date:       2008-03-24 11:12:26
Message-ID: 200803241212.28949.caslav.ilic () gmx ! net
[Download RAW message or body]


> [: Nick Shaforostoff :]
> What I eager to know is whether particular points/my whole work are needed
> at all [as part of Lokalize or even KDE project]. [...]

That's strongly put :) It really depends most on what Lokalize's authors --
meaning you for the moment -- want of Lokalize to be.

I personally would think that some of the features are not that useful for
the "usual" free software translation workflow: low volume, PO centric,
translators as users of (quite a bit) of what they translate, easy
communication, code available. E.g. anything about XLIFF support would fall
into the line of not-so-useful features.

On the other hand, there are features of Lokalize that I consider extremely
useful to the above type of translators, and that I try to emulate with
Pology scripts :) Diff display when old originals are available in POs is
one such, especially when it comes to translations with a lot of long
strings, like docs. The sync mode, used for proof-reading the modifications,
also looks quite a bit more useful than a plain file-level diff.

Of the planned features, any scripting capabilities, like custom auto-check/
mod scripts provided by users, is good for granted. Same for opening the
source files by PO reference.

Now for a possibly interesting bit, beyond mere feature wishlist. I'm not a
user of dedicated PO editors, nor I intend to be by the current outlook; it
simply happens that the text editor + scripts approach suits me better.
However, since many people feel more comfortable with feature-rich PO editor
(or CAT tool to name it), I thought of describing a few features that in my
opinion Lokalize could provide. And a "strange" thing happened: as I was
writing them down, I started realizing that Lokalize either supports the
effect that I was striving for, or just needs a slight tweak to do so, but
based on different "frame of mind" so to say :)

Thus, right now it seems to me that an important part of Lokalize's
deployment would be thinking (or inquiring) about translator's workflow
practices as they are, and then describing how they can be supported by
Lokalize, hopefully more efficiently. (Actually, this is one of the original
"features" I had in mind, but thought of it purely as "doc too spartan, add
verbosity", which wouldn't mean much.)

After this, none of my original feature recommendations have survived the
gauntlet to the extent of still being distinct enough for GSoC goals :) But
here they are regardless:

* "For-reference" find in files: instead of going through matched entries
  (switching opened POs), list all matched entries across POs in a new
  window, so that the user can skim through them. The interface could
  possibly be another checkbox, or two search buttons, in the find in files
  dialog.

  I had a much stronger wording for this initially, but then
  realized this is for the most part already covered by the translation
  memory queries, and even more by planned glossary/stemming approach. Still
  I think it could be useful, and not a lot of work; on the other hand, you
  may want to avoid it to "press" the TM workflow :)

* Msgid diff by matching msgstr. When the POs are not merged with --previous
  option, for a fuzzy message the exact msgstr could be looked up in the
  translation memory, and the corresponding stored msgid used to make the
  diff (in the "Original Diff" pane, possibly with a note that the source is
  TM).

  Again, I thought about this as much more important, until I figured
  out that it is already covered by the translation memory suggestions
  (which also give diffs). Nevertheless, I think that this feature could be
  a good default best guess from the the TM (especially for long messages).

* More language/languages for reference. Sometimes translators know more
  than English, and can use those other languages' PO for reference (this
  request pops up here and there, to the point that Gettext tools themselves
  have some features in this regard). It could be yet another msgstr pane,
  or a shortcut-activated popup something, since the user would probably
  refer to the other language only occasionally.

  Unsurprisingly, this could
  also be covered by TM -- simply make a TM/glossary out of those other
  languages, and use them for searches/suggestions. But, this somehow
  jumbles the materiel together, so possibly a separate functionality is
  worth it.

* Concerning the widget layout, I can't seem to stack anything directly
  below/above original/translation panes, in the sense that its width is
  synced to these two panes. In my opinion, this would be particularly
  useful for diff-containing panes. Unless possible already and I missed it,
  this would be a layout improvement.

-- 
Chusslove Illich (Часлав Илић)
Serbian KDE translation team

["signature.asc" (application/pgp-signature)]

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