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