A patch for several t()s

There are 2 kinds of t() fixes in this patch:

- The straightforward ones, for a missing t().

- Several cases where there are concatenations and function calls inside a t(). The problem with those is that the string extraction script does not handle them (it only gives a warning message), so they are never extracted to be translated, which makes the t() practically useless. I split those into concatenations of simpler t() calls. I believe the fixes are ok but I am not very experienced, so these need review.

- I did not fix several cases involving %name and %site, either without a t() or missing the parameter array, because I did not know where to use '%name' => '('Your Name')' or '%name' => $edit['yname'] or '%name' => l($edit['yname'], ... etc in the parameter array.

Updated patch to give some context to "by" so that the translator know what it is about.

Nice!

Here is a new patch for the updated version, for the last 7 problems for which the string extractor protested.
I left a comment in the first patched line because I thought that something has to be fixed there -- either the code or my comment :)

Sorry if it does not work. So, these extracted strings won't get the value at runtime?

I was only concerned with having "something %name something more" extracted and translated to "translation %name more translation".

I assumed that this was enough for getting the value at runtime, but I am not a coder. What about an additional outside t(), so that the internal one gets the strings to the translation while the external one will take care of run-time, and let the string extractor script protest? (not sure if the script would eat that)

Another one. I played it safe this time. Four strings in apparently trivial lines of code.

These are important because their text is the same as the text of the ones which shouldn't be touched, so those can be serviced too. I guess the same could be achieved by inserting dummy lines of code containing the needed text for the difficult cases, because neither the extraction nor the tranlator care for what the parameters represent.

I browsed the module's pages and everything appears to translate ok except one thing. The "email this page" link does not translate. Its translation string exists, my database cache is cleared *and* disabled, and still the link appears in English. This must be a recent problem. Maybe an unwanted t() somewhere which ruins a comparison? I don't know...

The same is true for "email this story" and the other node types. The link appears untranslated, not retrieved from the database.

When it is a form it does not have this problem.

An unrelated minor glitch I noticed while tinkering is that the link appears on the front page always, and the "Show link on main page" check box does not have any effect. This seems to be a result of the 'if-else' clause at line 621 which does exactly the same things in the two branches. Since the 'else' clause means ("we are on main" AND "don't show on main"), or so DeMoivre would say, 'else' shouldn't do much.

Still a mystery why "email this page" does not translate.

Oh, I just noticed that the "email this %type" string is not extracted at all. Never claimed to understand php...

Got it!

The t() calls containing %type parameters needed single quotes, not double quotes! It worked, and a couple of other strings came through as well.

I am rerolling the last small patch with this one.

Updated to add one more from theme.