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

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:
  1. Multiple project versions (1.0, 2.0, 3.0), same translation "kaput" in each version
    1. I am entering a new translation for version 3.0 "werden"
      1. 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_.
    2. I am entering a new translation for version 2.0 "gegen"
      1. 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_.
  2. 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")
    1. I am entering a new translation for version 3.0 "zwischen".
      1. 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_.
    2. I am entering a new translation for version 2.0 "sondern".
      1. 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

Back to the top