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