Translating talk:StatusNet
- [View source↑]
- [History↑]
Contents
Message docs and message source does not match. Docs say that the error is permanent, while message source indicates it is a temporary error.
Docs say this is a client error, but in that case why doesn't it just say "The file is too big"?
The source update was accidentally done on the translation. Edit: Hmm ... no, the !!FUZZY!! was interpreted as a translation.
to what refers this 'you'? to 'you and somebody like this?'
then german translation would be 'Dir' ... 'gefällt das', instead of 'Du und jemandem gefällt das'.
What does pinging mean here exactly?
The description says that "#. TRANS: Plural is decided on the total number of users liking the notice (count of %%s + %d)."
In fact this would be useful only for deciding the plural form of the verb, but wrong for deciding how to generate the correct singular or plural form of "other/others" which is NOT the total number of users, but only %d (which may be only 1. When this extra number is zero, another resource is used, without "and %d other(s)".
As Gettext cannot take several numbers to generate plurals, it would be more convenient to simply separate the expression "%%s and %d other(s)", to be generated first (using total minus 4, when the total is larger than 4), before inserting the generated string into "%%s liked this", which will take the singular or plural form of the verb according to the total number of users.
No ! It is INCORRECT, because the generated plurals are just for conjugating the verb.
Here it is ALWAYS plural in French because the verb is conjugated according to the total, but the term "autre" takes the singular or plural. This is equally true in English. E.g. in English : "Peter, Paul, Jack, John and 1 others liked this". 5 people total, but only 1 "other"; the verb is always conjugated as with the plural "they". "Peter, Paul, Jack, John and 10 others liked this". 14 people total, but 10 "others"; the verb is always conjugated as with the plural "they", "others" is now correct.
Please reconsider my message, the description does not solve the problem for "other/others" and the plural is needlessly tested on the verb which will always be conjugated with the plural (in most languages, except Slavic languages that have complex rules for plurals ignoring the hundreds and with several other forms using a genitive for some units) as there are always at least 5 people concerned in the subject.
Note also that the effective code passes the number ($count - 3), not ($count) to gettext, so the plural form will be selected by Gettext according to the wrong number. This will fail for all Slavic forms (for which you must pass up to 4 distinct forms to gettext).
If the code was supposed to pass the number of "other(s)", it should be ($count-4), not ($count-3). And you would have no hint to correctly conjugate the verb !
In other words, the message is buggy, but the code too ! The only "safe" translation is to assume the plural everywhere, without even using the plural template syntax in the message.
Note that for Slavic languages (Russian, Serbian, Czech, Slovak, Bulgarian...), Gettext will be used like this with the template syntax shown: dual See the declaration of plural conditions at the beginning of .pot files for those languages, which determines the number of forms taken for number forms (usually you don't need to provide it, TranslateWiki.net already knows that and generate the line for you for each supported language)
Can you propose a different wording? Or clarify more the context? I'm not sure about my translation. Thanks!
PLURAL should be applied for both parameters separately. Or message should be broken on two/tree if StatusNet could not support this.
Space between sentences is missing. Will be good idea to check other messages for similar problem.
Where is the statusnet-i18n mailing list? the link is broken here...
I've asked on the statusnet IRC channel. Will let you know if there is a reply. You can also use the StatusNet bug tracker at http://status.net/open-source/issues.
What do these messages mean when they refer to "salmon"?
- Ostatus-2a74b95df9ef4a88fa54d1a9f322bcd7dd8f980a-Salmon invalid actor for signi (“
Salmon invalid actor for signing.
”) - Ostatus-d109a2b46125ad81313cd02d38c9ecf69c705036-Salmon requires "application m (“
Salmon requires "application/magic-envelope+xml".
”) - Ostatus-330315b2738133ffa86b665e49d7ea28c968baae-Salmon signature verification (“
Salmon signature verification failed.
”) - Ostatus-500f991631de906d2ca665676cce92c3f4923fc3-Salmon post must be an Atom en (“
Salmon post must be an Atom entry.
”) - Ostatus-05018fa68d1e0043d1906dc8598aa3bbeb338adc-Received a salmon slap from un (“
Received a salmon slap from unidentified actor.
”)
The Salmon Protocol is an open, simple, standards-based solution that lets aggregators and sources unify the conversations. In OStatus, Salmon is used as the messaging transport for comments, replies, and notifications between users[1].
About StatusNet:Yammerimport-9b612078f70d5acd6c8960feb31391340fcfbe57-This Yammer import tool is sti/en
...on the Yammer side or ...on the Yammer site? Is that a typo?
StatusNet:0326b7077c453bc83aa6dd64b0ce4343526924ba-** s** has an account on site./en has trailing whitespace
This message contains trailing white space (see backslash at the end). Will be good idea to check all StatusNet messages for similar issue, since it's second one I found.
Is trailing backslash intentional or jut mistake?
Email subjects shouldn't have a full stop.
Should say 'List', similar to the issue in Thread:Support/About_StatusNet:42744ef97c02abe958450d194e1797e876145d93-Tagged/ar. Please see also:
Other button titles do not end in dots. I don't really know whether titles should or shouldn't end in dots, but please either remove the dot from this message or add ones to the others. See also:
All sentence like button titles should end with a period, and most do. Not high priority to change, I'll take care of it someday. Thanks for the report.
Would it help if I committed the change so you can pull to the upstream?
I've made a few code changes (more than you have highlighted above). It's probably not yet fully consistent, but at least more consistent now :).