[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [babel-dev] Translations and Project Versions
|
Gabe O'Brien wrote:
I am looking into your hairy query right now.
Yeah ... don't ask me how it works, 'cause I'd have to think about it. ;)
Does this insert multiple translations (one per version with the same
old translations)?
Yes.
One issue that this query doesn't address is the user interface
side. I might have to perform string comparisons for every
string/translation show just to show which other version are using the
same translation string (so they can see what the effects will be).
Ah. Then disregard everything I said .. although the "select" portion
of that insert will indeed find all the translations (for a given
language) that would need to be updated.
D.
gO'
Denis Roy wrote:
Gabe O'Brien wrote:
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).
If anyone has a simpler idea I am all digital ears.
I actually put some thought into this, and I think you can get away
with it in a fairly efficient manner without creating a table. I
simply replaced the single 'INSERT INTO translations' SQL query with:
INSERT INTO translations SELECT S.string_id, 2, "Some Enhanced Text",
other fields..... FROM strings AS S inner join files AS F on
F.file_id = S.file_id inner join translations AS T on T.string_id =
S.string_id where F.project_id = "eclipse" AND F.name=(SELECT
files.name FROM files where file_id = 7) AND S.name="pluginName" and
T.value = "Some Old Text" AND T.is_active = 1
I actually set up my database with data and tested this. The only
part of that query that would need to be optimized is *T.value =
"Some Old Text"*, which will perform poorly if the translations table
grows beyond 100,000 rows. Of course, if we move the old, inactive
translated stings to translations_archive as I suggested initially,
then the translations table should never really grow all that big.
It also depends on how many new translations/minute we'll get. I
don't think it will be huge.
At this point, I'm on the fence. Go ahead with your linking table if
you're more comfortable with that.
Denis
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?
--
[end of message]
------------------------------------------------------------------------
_______________________________________________
babel-dev mailing list
babel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/babel-dev
------------------------------------------------------------------------
_______________________________________________
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
------------------------------------------------------------------------
_______________________________________________
babel-dev mailing list
babel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/babel-dev
_______________________________________________
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