A table along these lines will be needed to reduce the pain for the
database. Otherwise when we add a new translation we would have to do a
bunch string comparisons to see which previous versions had the same
translation (and need to be updated).
How about a table like this:
create table strings_same_translation (
project_id varchar(100),
translation_set int default 0,
string_id int
);
IMPORTING PROJECT:
New Project:
For each new string insert the strings id/project.
Existing Project:
Find the previous strings translation_set and insert the new
strings id/set/project.
NEW TRANSLATIONS:
Update all with same Translations for Project:
No change to string_same_translation table, but need to insert
new translations for all associated strings.
Update only this Project Version:
Change this strings translation_set
if there is a equal translation to the new one set the string
to this translation_set
else create a new id (max for that project)
If anyone has a simpler idea I am all digital ears.
gO'
Bjorn Freeman-Benson wrote:
I think we need another table that links the separate strings in
different project versions together.
Gabe O'Brien wrote:
It
seems that most people (that have spoken up so far) like the plan of
having a unique set of translatable strings for every version of a
project? This is currently the way that we have implemented the
database and the import tool (from Kits original spec). So nothing has
changes, at this point.
Gabe O'Brien
Denis Roy wrote:
So in the end, what does the schema look
like? Any changes?
--
New Page 1
[end of message]
_______________________________________________
babel-dev mailing list
babel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/babel-dev
|