[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]