So in the end, what does the schema look like?  Any changes? 
 
Bjorn Freeman-Benson wrote:
  
  
There are a number of cases for a given string: 
  
    - Multiple project versions (1.0, 2.0, 3.0), same translation
"kaput" in each version
 
     
    
      - I am entering a new translation for version 3.0 "werden"
 
      
        - I should be prompted as to whether "werden" should be used
for previous versions (1.0, 2.0) as well. 
 
Bjorn thinks the default should be _yes_. 
       
      - I am entering a new translation for version 2.0 "gegen"
 
      
        - I should be prompted as to whether "gegen" should be used
for
previous versions (1.0) and later versions (2.0). 
 
Bjorn thinkgs the default should be _yes_. 
         
       
     
    - Multiple project versions (1.0, 2.0, 3.0), different
translations
"kaput", "werden" in each different versions (3.0="kaput",
1.0,2.0="werden")
 
     
    
      - I am entering a new translation for version 3.0 "zwischen".
 
      
        - I should be prompted as to whether "zwischen" should be
overwrite previous versions (1.0, 2.0) as well.
 
Bjorn thinks the default should be _no_. 
       
      - I am entering a new translation for version 2.0 "sondern".
 
      
        - I should be prompted as to whether "sondern" should be used
for previous versions (1.0) and should overwrite later versions (3.0).
 
Bjorn thinks the default should be _yes_ to the former and _no_ to the
later. 
       
     
   
   
My basic philosophy here is: if it's the same string, the same
translation, the prompt should default to yes. If it's the same string,
different translations, the prompt should default to no.  And, of
course, I hate pop-ups, so Gabe will have to figure some wonderful and
subtle UI clue about what is going to/should happen. 
   
- Bjorn 
   
Mike Milinkovich wrote:
  
    
    
    New Page 1
    
    
    It
sounds to me like we might be confusing database schema with
user workflow. 
     
   
Well, sort of and sort of not - certain database schemas will prevent
certain workflows. 
  
    
     
    But
at the same time, hard-wiring into the schema that if a string
is changed for version X of a project that it would automatically and
irrevocably also be changed for version X-1 of a project sounds counter
to good
software engineering practice. I think the schema itself should support
a
unique mapping of string to version and we can have tool or workflow
support to
define the scope of a new or modified string. 
     
   
   
  --  
  [end of message] 
  
 
_______________________________________________
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 
 |