[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic