[ mailman-Bugs-1999387 ] Misleading question in Subscribe WWW form.
Bugs item #1999387, was opened at 2008-06-21 13:27 Message generated for change (Comment added) made by keinstein You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1999387&group_id=103 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: (un)subscribing Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tobias Schlemmer (keinstein) Assigned to: Nobody/Anonymous (nobody) Summary: Misleading question in Subscribe WWW form. Initial Comment: Hi, At least the German translation is misleading on the subscription confirmation page of Mailman 2.1.5 as I have seen the same should be true in current trunk revison. The problem is that the Question "Nachrichtensammlungen abonnieren? Nein Ja" doesn't contain any information, that this setting is the delivery mode. It could be interpreted as "Yes, I really want to recieve emails from the list." I think the text of the default is much better to understand and would less likely loose so much information in any translation. So I suggest to change the message "Receive digests? No Yes" (in German: "Nachrichtensammlungen abonnieren? Nein Ja") to "Which delivery mode shall be used? Regular Digest" (in German "Welcher Auslieferungsmodus wird gewnscht? Normal Nachrichtensammlung") Btw.: The term "Nachrichtensammlung" just tells that it's a collection of messages, but nothing that it is deliverend as one Email containing the collection. I'd prefer to emphasize that its one email containing a collection, in German: "Sammelnachricht". That this collection will be a collection of messages shuld be easy to understand, since we are in a context of mailing lists. ----------------------------------------------------------------------
Comment By: Tobias Schlemmer (keinstein) Date: 2008-06-27 16:45
It doesn't work that way. The English text is the key used to look up
Message: Logged In: YES user_id=831067 Originator: YES Thanks for the hint to the UI discussion. I don't want to join a general discussion, I'm just an mailing list administrator arguing for his end users. As I'm not the server admin I can't provide much help in the development. But as this message is seldom read and easyly overlooked by developers I'm reporting it here. the
translated text in the target language's message catalog. Change one character in the English text, and the message will no longer be translated.
This is simply not true. Try something like for d in trasnslation_dir/*/LC_MESSAGES/mailman.po ; do sed -i.old -e 's,"Receive digests?","Deliver messages as digests?",' $d ; done on any machine where sed is GNU sed. And make the same change in the program file. If you are afraid of the yes/no issue, leave it as it is. If I'd have installed mailman on one of my computers I'd send you a patch, but I simply can't test it. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-06-21 19:01 Message: Logged In: YES user_id=1123998 Originator: NO
So your answer sounds to me as the answer of a technician. But the end user needs another solution.
It is the answer of a technician. I tried to explain the technical considerations which I feel prohibit me from making this change on the 2.1 branch. If you want to discuss consistency, semantics and usability of the web interface in future releases, this bug report is not the appropriate place. The appropriate place is the mailman-developers@python.org list <http://mail.python.org/mailman/listinfo/mailman-developers>. There is an existing thread at <http://mail.python.org/pipermail/mailman-developers/2008-June/020256.html>. There is also the wiki page at <http://wiki.list.org/x/RoBE>.
In the stable branch, just change the english text to be more explicit and use the old translations in any language.
It doesn't work that way. The English text is the key used to look up the translated text in the target language's message catalog. Change one character in the English text, and the message will no longer be translated.
Both are formulated as yes/no questions, but the "or" answers "Regular" and "Digest" are also valid answers.
I'm sure that's true in many of the translations, but I can't guarantee that it's true in all 35 translations. ---------------------------------------------------------------------- Comment By: Tobias Schlemmer (keinstein) Date: 2008-06-21 18:18 Message: Logged In: YES user_id=831067 Originator: YES The problem is: Even the English translation leaves too much room for misinterpretations. The "exclusive or" is not expressed. In fact it can be interpreted as "Recieve digests, too". So your answer sounds to me as the answer of a technician. But the end user needs another solution. There should be some consolidation, anyhow. At the moment even in the english translation the same feature is described at different locations in at least three different ways. This makes the communication between the everage user and administrators problematic. Most end users don't know about digest modes (or any other feature). So if the admin uses term A and the end user reads term B he won't be able to combine them, regardless the language. The best way would be to use the same terms for all the interfaces (user, admin defaults, registration). Unfortunately the user configuration pages are stored as a monolithic HTML page in the .po file. Maybe it is possible to store the strings seperately? Or field wise and generate the appropriate pages according to the settings, if either the admin changes them (if the page was not modified manually) or on explicit request? What about the following solution: Consolidate the messages in the development branch, breaking the languages. This must be possible in any software project. In the stable branch, just change the english text to be more explicit and use the old translations in any language. Some of them are already more descriptive. This should be possible using a simple sed script. The language maintainers should be informed about that and can decide if they have already a good translation or if they want to change anything. Two examples (as far as I can read them) with English and German translation: Polish: Grupowa listy w paczki? English: Group messages in digests? German: Post in Sammelnachrichten gruppieren? Czech: Dostvat pspvky jako digest? English: Deliver messages as digests? German: Post als Sammelnachrichten zustellen? Both are formulated as yes/no questions, but the "or" answers "Regular" and "Digest" are also valid answers. I'd prefer the latter two as they provide some synonymic redundance, which makes it easier to understand the question in the right way. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-06-21 16:55 Message: Logged In: YES user_id=1123998 Originator: NO Thanks for your input. There are a couple of problems for your suggestion at least as it pertains to the 2.1.x branch (the translation is the same in 2.1.11rc1). The text "Receive digests? No Yes" is actually three strings - "Receive digests?", "No" and "Yes" which are translated separately. Changing the English to "Which delivery mode shall be used? Regular Digest" would require translation of the three strings "Which delivery mode shall be used?", "Regular" and "Digest". It happens that "Regular" and "Digest" are already translated (German = "Normal" and "Nachrichtensammlung"), but "Which delivery mode shall be used?" or anything similar is not. Thus if the English were changed 34 other translations (not counting German) would be broken. Thus, I won't change the English at this point. Given that, if you can suggest a better German translation of "Receive digests?" that would be answered "Nein" or "Ja", I will update the German translation of "Receive digests?" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1999387&group_id=103
participants (1)
-
SourceForge.net