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

List:       kde-i18n-doc
Subject:    lokalize GSoC application
From:       Nick Shaforostoff <shafff () ukr ! net>
Date:       2008-03-19 9:31:52
Message-ID: 200803191131.52990.shafff () ukr ! net
[Download RAW message or body]

Hi everybody. Google Summer of Code 2008 is approaching,
and I would be grateful if I was chosen to participate in it again (i'm a \
3rd-year CS student now).

Right now I'm implementing XLIFF editing: during the last week i've \
realized support for editing entries with inline markup, but user can't \
insert new markup (copy it from source) yet.


These are the things I'd like to do during the summer (in priority order):

-Implement the most complete XLIFF support in the market
(incl. meta data editing, workflow assistance -- initial translation, \
                review, approvement)
-- 2 weeks [of full-time work]

-Adapt internal translation memory database to XLIFF/TMX -- store inline \
                tag information, match data, etc
-- 1 week

-Make Lokalize scriptable using Kross: implement various quality checks, \
svn integration, filters for other formats like ODF, LaTeX (reuse existing \
python scripts like [2]), wizards (?), reintegrate google-translate access \
(btw it is very useful for translating geographic names), Opening source \
code by references in message comments, ... (see [1] for more uses) 
-- 2-3 weeks

-Glossary checklists: check for forbidden terms/source-target pairs in new \
                translations, add them from editor
-- 1 week

-Automatic Glossary building based on translation memory.
I think this should be done in background for every file opened.
Autogenerated glossary entries may be displayed for current translation \
unit (msgid/msgstr pair) and then translator may choose to add them to a \
static glossary We will need morphological analyzers/bases for this (to get \
infinitive form of words). I will implement such 'plugins' for English and \
Russian (i've already found databases for that; shouldn't be problem to add \
support for more languages though). ==> By the way, should this feature \
                belong to strigi?
-- 2 weeks


If I still have time:
-go through bugs.kde.org and OmegaT bugzilla and try to satisfy as many \
wishes as possible.

-implement qt-linguist .ts format support

-strigi integration: use it for fast (non-regexp) searches, to find files \
that contain strings from TM



My ideas are close to the ones of 'Translate Toolkit & Pootle' project [2], \
but I'd like to implement them in KDE/Lokalize framework.

What I eager to know is whether particular points/my whole work are needed \
at all [as part of Lokalize or even KDE project]. Also, if you'd like \
clarification on any point, please ask!


[1] http://techbase.kde.org/index.php?title=Projects/Summer_of_Code/2007/Projects/KAider
 [2] http://translate.sourceforge.net/wiki/developers/gsoc2008_ideas


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