Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [babel-dev] Translations and Project Versions
I am looking into your hairy query right now. Does this insert multiple translations (one per version with the same old translations)? 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). 
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

Back to the top