[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [babel-dev] Translations and Project Versions
|
Gabe,
Thanks for the update.
As per todays' call, I'm not sure we all agree with the project/version
layout that is suggested below. As Kit mentioned, his design idea calls
for each version to have its own set of translatable strings, with the
import process dealing with the merge. Kit's idea also allows for newer
versions to drop strings that were there in past versions.
My vote is to leave the project/version/string setup as-is: each version
with its own set of translatable strings.
Thanks,
Denis
Gabe O'Brien wrote:
Greetings Bablers,
With the new year ahead of us and holidays behind us it is time to
peer into the future and see what we can do to get babel up and
running. I am starting by reworking the database a bit. My goal is
to change the database as little as possible while making the future
better.
The basic issue I am running into has to do with projects and
versions. The importing spec that we have been following
(http://wiki.eclipse.org/Babel_/_Server_Tool_Specification) (*note
this is a new location for this wiki page) doesn't really address
versions for projects.
What seems to make sense to me is that when importing an English
string (Bar) for project Foo version 1 we should only have one copy of
'Bar' for all future release of Foo (version 2,3,4..). This side
effect of this is will be if we change the translation of Bar it will
be changed in ALL versions of Foo.
One way to handle this would be to treat each Project/Version as
if it were is own project. So when we import a new .property file we
look at each key/value pair and see if that key/value/filepath already
exists (in the srtings table), if so we use it. If not we add a new
entry into the strings table.
This requires adding a new table (call it filestrings) that will
map all the incoming strings from a file (hence the clever name).
This new table will simply hold 2 keys one to the file table, and one
to the strings table.
Below is the old merge algorithm and below that is my new proposed
algorithm.
====Input Merge==== (OLD)
# For each key-value in the Babel database, check if the key exists in
the input. If not, delete the key-value from the Babel database
(saving it in the audit trail and history), of course.
# For each key-value in the input, check if the key exists in the
Babel database.
## If so, check if the value is the same.
### If so, no action.
### If not, replace the value and mark all translations as potentially
incorrect.
## If not, add the key and value to the Babel database.
====Input Merge==== (PROPOSED *note has a new table filestrings)
#For each key-value in the input
## if key-value exist in strings table and is from the same file
### True add link from filestrings table to the existing entry in the
strings table
### If not, insert a new key and value into strings table and make
link in filestrings
If anyone has input or concerns please let us know. The current
database schema can be found in CVS for the babel project (the file is
'babel-setup.sql').
Thanks,
Gabe O'Brien
Darn Good Developer
The Eclipse Foundation
_______________________________________________
babel-dev mailing list
babel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/babel-dev
--
Denis Roy
Manager, IT Infrastructure
Eclipse Foundation, Inc. -- http://www.eclipse.org/
Office: 613.224.9461 x224 (Eastern time)
Cell: 819.210.6481
denis.roy@xxxxxxxxxxx
