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]
|
