Update en_US.inc #55
Update en_US.inc #55
Conversation
| $labels['preference_compose_subject_exact'] = 'Is one of the recipients'; | ||
| $labels['preference_compose_subject_always'] = 'Always enable default identity'; | ||
| $labels['preference_compose_subject_domain'] = 'uses same domain as one of the recipients'; | ||
| $labels['preference_compose_subject_exact'] = 'is one of the recipients'; | ||
| $labels['preference_compose_subject_never'] = 'Never enable automatically'; |
There was a problem hiding this comment.
Why is this one starting with an uppercase character while others were lowercased? I don't have a strong preference (uppercase for menu items seemed OK to me), but I think it should stay consistent in any case.
There was a problem hiding this comment.
When the answer builds a complete sentence with the setting's function, it makes sense to showcase this by lowercase. When the answer is an own sentence, this is indicated by starting with uppercase. This helps identifying that the answer is not directly related to the setting as enabling does not come down to the fact whether or not "one of the identities is..." but – as I understand – the default identity or, respectively, the plugin is (never) enabled independent from condition in line 10. Maybe one could specify in line 14 "Never enable custom address automatically" for a swift clarification.
From my understanding, it would be more clarifying when function of line 11 and 14 are not related to line 10, so maybe they should rather be a triple-toggle setting together with condition of line 10. When the option "Enable when one of my identities" is enabled, it could trigger a secondary option with settings specified in line 12+13.
There was a problem hiding this comment.
OK, I see your point. Let's go with this 👍
Minor improvements to upper/lower cases in English localization.