I understood from the earlier comments of Jan that this was a better 
way of dealing with gettext strings. Keep them as simple as possible, 
so that a change in formatting or otherwise similar uses get 
translated without additional effort. Apparently, I misunderstood his 
comments.
If you look more closely, you'll see that the semicolon in the '°' 
was missing, which I added later on. I didn't make a difference in 
output.

Added the missing units, and the additional space, but I didn't break 
out the sprintf() strings into pure concatenation as your patch did. 
Not sure why you wanted it that way.

Also, the patch that accompanies the "add missing semicolon" comment 
doesn't appear to do anything different than the first patch - and 
doesn't add any semicolon...

Changes have been made in Git for this ticket:

Add missing wind units, tweak.
Bug: 10829

  1 files changed, 10 insertions(+), 4 deletions(-)
http://git.horde.org/horde-git/-/commit/42af8f8f80d908e26974d7faea50a910fada8bd5

Adding missing semicolon

Funny enough, the subject was not fixed by these modifications. Adding 
new patch against Git Master, that also consolidates the gettext 
strings used in the current wind condition and wind forecast.

This is generally true and a common problem when using gettext for 
translations.
This doesn't make sense. The idea behind the gettext approach is to 
*avoid* strings that only have minor difference, to make the 
translator's life easier and reduce redundancy. Adding arbitrary 
punctuation or whitespace just to allow different translations is 
completely against this idea and actually makes it harder for 
translators.
No. Adding markup is completely unacceptable and even worse than 
adding whitespace or unnecessary punctuation.
This could be solved by using newlines instead, and wrap the 
translated text with nl2br().

I'm not to thrilled about some changes you made here. You removed a 
lot of context information from the gettext strings. :-)

For translators it is in many cases better to have an idea about the 
context in which words are used. For instance, the word 'at' can have 
at least half a dozen meanings in Dutch, depending in which context it 
is used. So I welcome the change in line 206, but something similar 
would be needed in line 313. In the worst possible scenario, someone 
would add a gettext where 'at' is used to indicate a location and at 
least for the Dutch translation I would run into trouble.

Also, you removed a number of ':' characters. As an example, until now 
I use different translations for 'Humidity: ' and 'Humidity'. In 
current conditions there is ample of space for the full translation 
'Relatieve vochtigheid' (the previous translation 'vochtigheid' is 
incorrect in this context), but in the forecast table this would take 
up way too much space, so here the abbreviation 'RV' (which is also 
common) is used. By removing the colon, I have no way to make this 
difference anymore. In fact, it would prefer (in table headers) to 
include the HTML codes <th> and </th> in the gettext string, so that 
for a translator it is immediately clear how this string is used (and 
that a short translation is preferred over a longer one).

Last, you also changed the "Precipitation<br />chance" to 
"Precipitation%schance", effectively hardcoding the <br /> in the 
process. Even if a language would have a very short translation for 
this, the break is now mandatory. I can imaging that for instance in 
Japanese of Chinese this would require a few characters, making the 
break undesireable.

We really shouldn't go down the road of removing all context 
information from the translation, since that will degrade the quality 
of translation.

The strings should be mostly cleaned up now.

Changes have been made in Git for this ticket:

Clean up some strings.
Related to Bug: 10829

  1 files changed, 30 insertions(+), 38 deletions(-)
http://git.horde.org/horde-git/-/commit/6f48d4e8da58491255c7b498b5c67a187db9b108

Yeah. Those should be cleaned up. I basically just ported the old 
weatherdotcom block's output. I've got a fix locally that I'll push 
when some other stuff I'm working on is ready.

Because in the forecast, the same string is used (line 321). Since not 
only the word but also the meaning is identical (wind direction and 
-speed), it made sense to me to use the same gettext string in both 
places. Since though the translation for ' at ' was already present, I 
changed the line earlier on to the same, so that other languages will 
benefit too without any effort from translators. Other than that, I 
have no preference for the space in or out of the gettext string.

I committed the fix for the precipitation chance, but I'm confused 
about your other change. Why are you moving the spaces into the 
gettext string?

Changes have been made in Git for this ticket:

Add missing assignment (Bug: 10829).
Signed-off-by: Michael J Rubinsky <mrubinsk@horde.org>

  1 files changed, 1 insertions(+), 1 deletions(-)
http://git.horde.org/horde-git/-/commit/72d709bc7c5262f039b50f41deb8b3a4149216c0

Add missing units on current wind condition and also fixes trivial bug 
on daily forecast precipitation change