314451 - matchAll.label should become different entities

Status: RESOLVED WORKSFORME

(Thunderbird :: Search, defect)

Description

[Hendrik Maryns]

The entity matchAll.label is currently used in three slightly different contexts, shich makes it rather different to translate it.  It is used in the adresbook search for adresses, where there is no string preceding it; it is used in message search, where there is a string and box ‘Search messages in: [box]’ before it; and it is used in the filter messages, where it is preceded by the string ‘For incoming messages that:’.  This makes it very difficult to translate this string.  There is no good dutch translation because of the ambiguity of the word ‘match’.

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Sipaq, this impacts l10n I guess..

Comment 2

[Hendrik Maryns]

Good to see that after 3 years (!) something is happening here!

Comment 3

[Simon Paquet [:sipaq]]

Attachment: Patch v1

Comment 4

[Hendrik Maryns]

Wow, you ’ve been thorough.  Thanks for this.

Comment 5

[Simon Paquet [:sipaq]]

Attachment: Unbitrot patch

Phil, not that Bug 490118 got fixed, can you please take a look at this? I know that it's not pretty, but it's the only solution I know. If you have a better idea, I'm happy to hear it.

If you don't can you please also suggest an appropriate reviewer for the suite/ part? I don't know the SM reviewers.

Comment 6

[Simon Paquet [:sipaq]]

Adding :l10n (:tb-l10n is not active yet) to get some feedback from Thunderbird and SeaMonkey localizers on the patch here in this bug. 

Is the approach to your liking? Do you have any improvement suggestions?

Comment 7

[Simon Paquet [:sipaq]]

Adding the shiny and new :tb-l10n alias to replace the l10n-community address.

Comment 8

[Simon Paquet [:sipaq]]

Comment on attachment 389328 [details] [diff] [review]
Unbitrot patch

Phil, any chance of getting a review anytime soon?

Comment 9

[Phil Ringnalda (:philor)]

Comment on attachment 389328 [details] [diff] [review]
Unbitrot patch

Sorry, I keep thinking I'll catch up, but it always turns out I'm wrong.

Issues so far:

* Even when the rest of the file doesn't look like it, we still want to wrap XUL at 80 columns

* The radiogroup needs to be exactly where searchTermOverlay.xul was putting it, as the first thing in searchTermListBox - this patch is breaking the layout of pretty much everything by putting it in random spots, like the filter editor having a horizontal box that contains both the radiogroup and the whole search terms condition box jammed into a tiny space at the end

* The only reason the matchAll radio had the id matchAllItem was because most things didn't actually want to have it, so there's a function named hideMatchAllItem to get rid of it - instead we should be getting rid of the item and the strings and the function calls for the things that don't want it, and getting rid of the function itself

* You missed adding the radiogroup to mail/extensions/mailviews/content/mailViewSetup.xul

Comment 10

[Simon Paquet [:sipaq]]

I'm not going to work on this in the foreseeable future.

Comment 11

[:aceman]

Is this still a problem?
It seems the wording in the filter dialog was changed since the report.
Can you check it out, Hendrik?

Comment 12

[Hendrik Maryns]

I still see matchAll.label when clicking on the url link above, although it is only used once.  So I guess the patch is still desirable.  Though I do not understand why it introduces like, 10 different occurrences.

The Dutch translation in the filter creation dialogue is acceptable now, though it could still be better.  That is due to the difficulty of translating ‘match’, and would require a different layout, something like:

...
Apply filter when: xxxxxxxxx
Apply filter for: o messages that match all of the following o messages that match any of the following o all messages.
...

I.e. an intro before the radio button (possibly empty, if you wish to keep it like this in English).

Comment 13

[:aceman]

The patch is big because when the one matchAll.label can't be shared across all search dialogs that use it, it must be duplicated (like 10 times) in all of them so that any of them can be different, just in case.

Comment 14

[:aceman]

I think this could be finished (the patch looks sane), but I do not like the duplication it is introducing.

(In reply to Hendrik Maryns from comment #12)
> The Dutch translation in the filter creation dialogue is acceptable now,
> though it could still be better.  That is due to the difficulty of
> translating ‘match’, and would require a different layout, something like:
> 
> ...
> Apply filter when: xxxxxxxxx
> Apply filter for: o messages that match all of the following o messages that
> match any of the following o all messages.
> ...
> 
> I.e. an intro before the radio button (possibly empty, if you wish to keep
> it like this in English).

I do not understand why you use the "intro" as the context for the "match ..." strings.
It appears to me that the strings apply to the search terms below them. I does not necessarily mean "messages that MATCH ALL OF THE FOLLOWING" and in other dialog "contacts that MATCH ALL OF THE FOLLOWING". Even though it would also make sense. In my understanding it means "(when searching of the relevant objects this dialog is about, the objects must) MATCH ALL OF THE FOLLOWING search terms". In this case the string matchAll.label can be the same in all dialogs, because also all the search terms blocks are the same.

Can you think about this? Maybe we could just add an "intro" text common to all dialogs that makes this interpretation obvious?

Comment 15

[Hendrik Maryns]

In fact, I have stopped contributing to Mozilla translations for a few years by now, but I don’t want to let you hanging here, so…

> (In reply to Hendrik Maryns from comment #12)
> > The Dutch translation in the filter creation dialogue is acceptable now,
> > though it could still be better.  That is due to the difficulty of
> > translating ‘match’, and would require a different layout, something like:
> > 
> > ...
> > Apply filter when: xxxxxxxxx
> > Apply filter for: o messages that match all of the following o messages that
> > match any of the following o all messages.
> > ...
> > 
> > I.e. an intro before the radio button (possibly empty, if you wish to keep
> > it like this in English).
> 
> I do not understand why you use the "intro" as the context for the "match
> ..." strings.
> It appears to me that the strings apply to the search terms below them. I
> does not necessarily mean "messages that MATCH ALL OF THE FOLLOWING" and in
> other dialog "contacts that MATCH ALL OF THE FOLLOWING". Even though it
> would also make sense. In my understanding it means "(when searching of the
> relevant objects this dialog is about, the objects must) MATCH ALL OF THE
> FOLLOWING search terms". In this case the string matchAll.label can be the
> same in all dialogs, because also all the search terms blocks are the same.
> 
> Can you think about this? Maybe we could just add an "intro" text common to
> all dialogs that makes this interpretation obvious?

If I understand you correctly (but it is quite complex to imagine, some pictures would help), you are right.  An introduction would solve it in all cases, which would make it unnecessary to split it up for all cases.  Of course, the introduction text would be different in each dialog.  It would also make the grammar of the filter dialog more logical: now it starts with ‘Apply filter when:’, followed by two checkboxes and then immediately the matchAll.label.  But matchAll.label does not fit the ‘when’ part.  So another line after the checkboxes like ‘For messages that:’ (matchAll, matchOne) would then fit nicely with ‘Perform these actions:’ (which should maybe not have a capital…).

And in the address book search the intro would simply be ‘Find/search messages that:’ (I leave the exact wording to an English native.)

In that case, in the Dutch translation, we could leave out the ‘Moet’ (has to), which makes it look so awkward.

Comment 16

[:aceman]

Thanks. I hoped the "intro" could be the same everywhere, but even different intros would be fine with me. Better than copying all the 3 labels.

Bwinton, Thomas, what do you think about the problem here?

Comment 17

[Thomas D. (:thomas8)]

Unless there's something in the Dutch translation which makes this an issue, I don't see the need to change anything around here. I believe I have a very good feeling for grammar but I don't share the grammatical scepsis of comment 15; I agree with aceman that the two captions here are independent of each other and I find that pefectly acceptable at least for EN:
- (specification 1) Search [for messages,addresses,...] in:
- (specification 2) Match all of the following | Match any of the following | Match all messages

In EN, 'search' and 'match' are both verbs in the same form, so it's consistent.
EN has the advantage that there's no difference in form between infinitive and imperative, so in conversation with software, this could mean either of:
- To search for ...(infinitive)
- "TB, search for ...!" (imperative)

Other locales like German and Dutch (I presume), have to choose between these two connotations, and German has fairly chosen infinitive:

- Nachrichten suchen in: (to search for messages in...)
- Alle Bedingungen erfüllen | Mindestens eine Bedingung erfüllen | Keine Bedingungen
(to fullfil all criteria/conditions | to fullfil at least one criterion | no criteria)

I imagine the Dutch translation chose to be more wordy, using the dutch for:
"must fullfill all of the following | ..."
In German, this would also make sense but is not required for correct translation.
I think concise style using infinitives is perfectly adequate when communicating with a software like Thunderbird where work is being done. No need to be overly wordy in the UI where space is limited. 

You can also see that translations like German correctly take the freedom to make the meaning more explicit by using "criteria/conditions" instead of "the following".

If there's an issue/linguistic oddity in the Dutch translation, I think that needs a new bug with STR, Actual Result, Expected result, and we'd really need to see screenshots (or at the very least the list of strings in question). So I think the best way forward is to close this bug wfm, perhaps after dissecting comment 9 and see if that needs a followup bug for minor code cleanup issues. Just my 2 cents.

Comment 18

[Blake Winton (:bwinton) (:☕️)]

Yeah, what Thomas said.  :)

Comment 19

[Thomas D. (:thomas8)]

So per Blake's comment 18, UX people seem to agree we don't need to change anything here on the global EN template. And it's not like this bug attracted any significant following, votes, or dupes...
-> wfm.

Dutch localization are free to improve their translation if required, e.g. to drop the "Moet".

Since we are stealing this little thing from aceman, we should offer him something in compensation :)
You may or may not want to look into this little code cleanup part of comment 9 (in a followup bug):

> * The only reason the matchAll radio had the id matchAllItem was because most things didn't actually
> want to have it, so there's a function named hideMatchAllItem to get rid of it - instead we should
> be getting rid of the item and the strings and the function calls for the things that don't want it,
> and getting rid of the function itself

I'm not 100% sure what this is about (and I don't really care ;), but this might suggest to remove the matchAllItem radio XUL element tag from those dialogues that don't use it, instead of having it on those dialogues and then hide it using code functions. So when the matchAllItem element is no longer present on those dialogues, the function hideMatchAllItem could be eliminated, too. Needs reflection if it's the right thing to do, and if done, needs care not to break things.

So for now, it's goodbye for this little bug :)

Comment 20

[:aceman]

I understood it that comment 9 was about what needs to be done to the patch. If we are not using the patch we probably can't do that fix.

Comment 21

[Thomas D. (:thomas8)]

FTR: Comment 0, i.e. the original description of this problem, was obsolete anyway because the underlying arrangement and wording of strings have changed significantly. So the original purpose and motivation of this bug was now largely historical, without clear focus...

(In reply to :aceman from comment #20)
> I understood it that comment 9 was about what needs to be done to the patch.
> If we are not using the patch we probably can't do that fix.

I thought that part of comment 9 might apply even independent of the patch, but it's very possible that you are right. I won't check ;)