1831908 - [meta] aboutAddressBook - many strings need proper pluralization

Status: RESOLVED FIXED

(Thunderbird :: Address Book, defect, P2)

Description

[Rob Lemley [:rjl]]

In aboutAddressBook.ftl, there's some strings that need updating due to poor pluralization.

https://firefox-source-docs.mozilla.org/l10n/fluent/review.html#variants-and-plurals

Require pluralization

• about-addressbook-selection-mixed-header
• about-addressbook-selection-contacts-header
• about-addressbook-selection-lists-header

Remove ${name} from singular form
The issue here is that "one" can cover 1 or 11 in some languages, so forcing a singular ${name} variable on [one] won't work. If possible, remove ${name} from the [one] form. If that's not possible, use a separate string to cover the 1 contact being removed and then a standard plural string for > 1.
https://github.com/projectfluent/fluent/wiki/Good-Practices-for-Developers#prefer-separate-messages-over-variants-for-ui-logic

• about-addressbook-confirm-delete-contacts
• about-addressbook-confirm-remove-contacts

Comment 1

[Thomas D. (:thomas8)]

(In reply to Rob Lemley [:rjl] from comment #0)

Thanks Rob for filing this!

Require pluralization

• about-addressbook-selection-mixed-header
• about-addressbook-selection-contacts-header
• about-addressbook-selection-lists-header

^^ Yes, these are obviously wrong.

Remove ${name} from singular form
The issue here is that "one" can cover 1 or 11 in some languages, so forcing a singular ${name} variable on [one] won't work. If possible, remove ${name} from the [one] form. If that's not possible, use a separate string to cover the 1 contact being removed and then a standard plural string for > 1.

Mind-warping stuff, let me share my learning curve here: I first thought that this is wrong, but after some more reflection, I think Rob is right. However, please do not just remove ${name} from the [one] form; for best ux-error-prevention and ux-control, it's clearly helpful to know which exact contact you're deleting. So we probably need to have a separate string for the 1 contact being removed case as per Rob's suggestion. The reason is not so much in the count (where [one] may cover 1 or 11 in some languages), but rather in the different message - things might break for such languages when they have to pack the name in that [one] form and then suddenly it applies to 11 contacts, too, where showing only the first contact's name doesn't make sense and may break the grammar. One would think that they could just use [1] selector instead then (and they probably could); however, that [1] form would still be structurally different because it has the variable ${name} which all the other forms have not, so it's a message which arguably serves a different purpose and is not just a grammatical singular/plural variation, so it should have it's own string. Please correct me if I'm wrong.

Here's the guide's example for different purpose (otherwise this is different from our case, as we won't need [one], we just need one plain vanilla plural form with the counter passed in imo):

# Separate messages which serves different purposes.
items-select = Select items
# The default variant works for all values of the selector.
items-selected =
    { $num ->
        [one] One item selected.
       *[other] { $num } items selected.
    }

https://github.com/projectfluent/fluent/wiki/Good-Practices-for-Developers#prefer-separate-messages-over-variants-for-ui-logic

• about-addressbook-confirm-delete-contacts
• about-addressbook-confirm-remove-contacts

Comment 2

[Elizabeth Mitchell]

(In reply to Thomas D. (:thomas8) from comment #1)

(In reply to Rob Lemley [:rjl] from comment #0)

Thanks Rob for filing this!

Require pluralization

• about-addressbook-selection-mixed-header
• about-addressbook-selection-contacts-header
• about-addressbook-selection-lists-header

^^ Yes, these are obviously wrong.

Remove ${name} from singular form
The issue here is that "one" can cover 1 or 11 in some languages, so forcing a singular ${name} variable on [one] won't work. If possible, remove ${name} from the [one] form. If that's not possible, use a separate string to cover the 1 contact being removed and then a standard plural string for > 1.

Mind-warping stuff, let me share my learning curve here: I first thought that this is wrong, but after some more reflection, I think Rob is right. However, please do not just remove ${name} from the [one] form; for best ux-error-prevention and ux-control, it's clearly helpful to know which exact contact you're deleting. So we probably need to have a separate string for the 1 contact being removed case as per Rob's suggestion. The reason is not so much in the count (where [one] may cover 1 or 11 in some languages), but rather in the different message - things might break for such languages when they have to pack the name in that [one] form and then suddenly it applies to 11 contacts, too, where showing only the first contact's name doesn't make sense and may break the grammar. One would think that they could just use [1] selector instead then (and they probably could); however, that [1] form would still be structurally different because it has the variable ${name} which all the other forms have not, so it's a message which arguably serves a different purpose and is not just a grammatical singular/plural variation, so it should have it's own string. Please correct me if I'm wrong.

Here's the guide's example for different purpose (otherwise this is different from our case, as we won't need [one], we just need one plain vanilla plural form with the counter passed in imo):

# Separate messages which serves different purposes.
items-select = Select items
# The default variant works for all values of the selector.
items-selected =
    { $num ->
        [one] One item selected.
       *[other] { $num } items selected.
    }

https://github.com/projectfluent/fluent/wiki/Good-Practices-for-Developers#prefer-separate-messages-over-variants-for-ui-logic

• about-addressbook-confirm-delete-contacts
• about-addressbook-confirm-remove-contacts

I came across something similar with OpenPGP string notifications. We can keep name and also convert this. In the case of the address book, for more than 1 item, the name variable would be an empty string (similar to $addr in this OpenPGP example).

# Variables:
# $addr (String) - Email address with key issues.
# $count (Number) - Number of recipients with key issues.
openpgp-key-issue-notification =
    { $count ->
        [one] End-to-end encryption requires resolving key issues for { $addr }.
       *[other] End-to-end encryption requires resolving key issues for { $count } recipients.
    }

Comment 3

[Elizabeth Mitchell]

(In reply to Rob Lemley [:rjl] from comment #0)

Remove ${name} from singular form
The issue here is that "one" can cover 1 or 11 in some languages, so forcing a singular ${name} variable on [one] won't work. If possible, remove ${name} from the [one] form. If that's not possible, use a separate string to cover the 1 contact being removed and then a standard plural string for > 1.

I don't understand. This needs to not be in this format (current code)?

# Variables:
# $count (Number) - The number of contacts to be deleted.
# $name (String) - The name of the contact to be deleted, if $count is 1.
about-addressbook-confirm-delete-contacts =
  { $count ->
     [one] Are you sure you want to delete the contact { $name }?
    *[other] Are you sure you want to delete these { $count } contacts?
  }

My suggestion before would then be incorrect then, right? Thank you!

Comment 4

[Elizabeth Mitchell]

This might need to be split up into smaller tasks so we can get this in more quickly. Unassigning myself for right now, but I plan to work on at least part of this.

Comment 5

[Elizabeth Mitchell]

Rob is checking in on how to handle pluralization when we are doing something special for a single case (see phabricator comment.)

Comment 6

[Elizabeth Mitchell]

Splitting tasks into separate bugs

Comment 7

[Elizabeth Mitchell]

I think these have all been addressed. If not, feel free to reopen or create a new bug.