final proposal for Issue #153

[paradix]

Could You please make a review and tell me if this solution is acceptable?
If yes, I will than finish it for all other languages and make some clean up in the code.

[paradix]

There are still some comments missing that will be needed for translators. But I will add them after You commented on this.

[jonasoreland]

Hi,

I'm not happy with the PR, sorry (but still like the concept!)

1. the existing cues should be unaltered (as strings, not MessageFormats)
2. the sentences should get new entries in cues.xml, they can be MessageFormat
3. new formatting preferably be in Formatter not in AudioFeedback

Don't you think above would work ?

/Jonas

[paradix]

Hi Jonas,

I get ghe point with moving the logic to the Fotmatter class, but I don't understand why You want the existing cues stay unaltered.

What will be the use of them? In this form they are useless e.g. for the Polish translation, as it needs many forms of verbs an nouns even for such easy sentences.

The whole point of my idea was to make an flexible mechanism that would leave the translator some space in creating the cue sentence.

The result is unchanged for English and Polish can be handled. I assume other languages can make use of this as well.

Regards
paradix

[jonasoreland]

My motivation for wanting the existing cues unaltered is

• it is significantly easier to translate single words
• even if this makes certain (all) languages grammatically incorrect, the
  effort of getting a reasonably good baseline is decreased.
• only few experts will use actually translate whole sentances

do you see what I mean ?

/Jonas

On Sun, Jan 18, 2015 at 11:47 AM, paradix [email protected] wrote:

Hi Jonas,

I get ghe point with moving the logic to the Fotmatter class, but I don't
understand why You want the existing cues stay unaltered.

What will be the use of them? In this form they are useless e.g. for the
Polish translation, as it needs many forms of verbs an nouns even for such
easy sentences.

The whole point of my idea was to make an flexible mechanism that would
leave the translator some space in creating the cue sentence.

The result is unchanged for English and Polish can be handled. I assume
other languages can make use of this as well.

Regards
paradix

—
Reply to this email directly or view it on GitHub
#170 (comment).

[paradix]

with that proposal You can leave the existing cues in this format:

<string name="cue_workout">0&#60;activity</string>
<string name="cue_activity">0&#60;interval</string>
<string name="cue_lap">0&#60;lap</string>
<string name="cue_started">0&#60;started</string>
<string name="cue_paused">0&#60;paused</string>
<string name="cue_resumed">0&#60;resumed</string>
<string name="cue_stopped">0&#60;stopped</string>
<string name="cue_completed">0&#60;completed</string>

It still would work, and the strings would be altered minimalistic.
Would that be a way out for You?

[jonasoreland]

not really,

what do you see as the downside of adding new strings for the sentences ? I
don't understand
(i think it's quite logical, strings for nouns/verbs and strings for
sentences)

/Jonas

On Sun, Jan 18, 2015 at 3:05 PM, paradix [email protected] wrote:

with that proposal You can leave the existing cues in this format:
0<activity
0<interval
0<lap
0<started
0<paused
0<resumed
0<stopped
0<completed

It still would work, and the strings would be altered minimalistic.
Would that be a way out for You?

—
Reply to this email directly or view it on GitHub
#170 (comment).

[paradix]

The problem is, that in other languages then English due to declension you might need more then one form of the noun, and due to conjugation more than one form of the verb.

Especially in Polish you have 7 different forms in the declension.
So with the format I have proposed you don't need to care that much about this, because the translator will have to make the proper decision.

You can't know how many strings you will have to add for nouns and verbs, as it is language dependant.

That's my point of view, but maybe I don't understand Your proposal.

[jonasoreland]

1. i'm more happy if i get 10 more languages translated, with grammatical
   errors,
   that if i get polish to handle 7 different forms of declension and
   conjugation.

2. as I see if, if you make the it easy to do an "easy" translation, you
   make the complicated infinitively complicated.
   i don't mind if you enumerate each combination of dimension/scope for
   different values.

so...handle more of polish FINE! but not that the expense of complicating
it for those that doesn't want to...

---

does that make sense ??

/Jonas

On Sun, Jan 18, 2015 at 3:49 PM, paradix [email protected] wrote:

The problem is, that in other languages then English due to declension you
might need more then one form of the noun, and due to conjugation more than
one form of the verb.

Especially in Polish you have 7 different forms in the declension.
So with the format I have proposed you don't need to care that much about
this, because the translator will have to make the proper decision.

You can't know how many strings you will have to add for nouns and verbs,
as it is language dependant.

That's my point of view, but maybe I don't understand Your proposal.

—
Reply to this email directly or view it on GitHub
#170 (comment).

[paradix]

Sorry I didn't mean to start a fight over this. Just thought this might actually be some added value to get it right. And with the option in my last comment it is not getting any more complicated for other languages. You would need to insert the substring "0<" into each cue.

But in the end it's up to you, as it is your application. Leaving the polish cues as they are translated now will still be understandable though not really grammatically correct.

[jonasoreland]

no worries. different opinions/perspective is good.
i'll look at your latest version tomorrow....

/Jonas

On Sun, Jan 18, 2015 at 5:14 PM, paradix [email protected] wrote:

Sorry I didn't mean to start a fight over this. Just thought this might
actually be some added value to get it right. And with the option in my
last comment it is not getting any more complicated for other languages.
You would need to insert the substring "0<" into each cue.

But in the end it's up to you, as it is your application. Leaving the
polish cues as they are translated now will still be understandable though
not really grammatically correct.

—
Reply to this email directly or view it on GitHub
#170 (comment).

[paradix]

OK, I will at least push a commit tomorrow with a re-factored version so you can see it all

[paradix]

Ok, now have a look. I have re-factored it, so most of the logic is now in the formatter.
Plus the cues.xml have been altered for all languages so you can see the whole scope of the changes.

[gerhardol]

Is this PR obsolete with the changes to nouns in 1.57?

[gerhardol]

Plurals are handled in v1.58
Is that enough to close this PR?