[josm-dev] Localisation policy for quotes etc.

[Karl Guggisberg]

Hi Andre

>  Ok, understood. Only thing is, that in Launchpad I cannot see whether it
>  is a MessageFormat or not. So I have to trust the original text to be in
>  correct format, haven't I?
Yes, you can. If there is at least one format placeholder {0}, {1}, etc. in the text you see in Launchpad, then you must escape all single quotes with another single quote. If there isn't, you shouldn't escape them.

Regards Karl


Am 10.01.2010 16:53, schrieb Andre Hinrichs:
> Am Sonntag, den 10.01.2010, 16:31 +0100 schrieb Karl Guggisberg:
>    
>> Hi,
>>
>>      
>>>   It's always a single quite in English, but perhaps they're double
>>>   quotes in the JOSM source to work around something?:
>>>        
>> tr("abc") doesn't use MessageFormat. A single quote in tr("...") therefore isn't a meta-character and is copied to the output.
>>     tr("a single quote ' ")  ->   "a single quote '"
>>
>> tr("a {0}", "test") uses MessageFormat. There, single quotes are meta-character. A single quote is the (close) equivalent to  \ in regexp: it allows to escape curly braces. '} is }, '' is '.Therefore, if you have a I18n string with format placeholders and single quotes, you MUST escape them with two quotes. If you don't MessageFormat won't process the format placeholders correctly and single quotes are deleted.
>>     tr("a single quote '' - {0} ", "OK")  ->   "a single quote ' - OK"
>>     tr("a single quote ' - {0} ", "NOK")  ->   "a single quote  - NOK"  (or "a single quote - {0}" because formatting fails)
>>      
> Ok, understood. Only thing is, that in Launchpad I cannot see whether it
> is a MessageFormat or not. So I have to trust the original text to be in
> correct format, haven't I?
>
>    
>> At least that's what you have to do today unless somebody changes the tr() implementations in I18n. If tr("...") was to use MessageFormat too, single quotes would always have to be escaped with another single quote.
>>
>>      
>>>   The HTML is rendered by some internal Java stuff, both of those tags
>>>   work just as well when fed to it so I don't think it needs to be fixed
>>>   either way.
>>>        
>> AFAIK, the internal Java stuff doesn't support "<br/>". Even worse, if you use it instead of"<br>" the HTML rendering is sometimes messed up. This holds for labels, tooltips and for JEditorPane.
>>      
> I'll check that later this evening.
>
>    
>> Am 10.01.2010 16:13, schrieb Ævar Arnfjörð Bjarmason:
>>      
>>> On Sun, Jan 10, 2010 at 15:00, Andre Hinrichs<andre.hinrichs at gmx.de>   wrote:
>>>
>>>        
>>>> Hi List!
>>>>
>>>> Since I currently check all translatable texts I found that sometimes
>>>> quotes are single and sometimes double. E.g. "isn't" is sometimes simply
>>>> "isn't" and sometimes "isn''t".
>>>>
>>>> Which is the correct way?
>>>>
>>>>          
>>> It's always a single quite in English, but perhaps they're double
>>> quotes in the JOSM source to work around something?:
>>>
>>> aoeu josm (r2766) $ ack "tr\(.*isn''t" src
>>> src/org/openstreetmap/josm/gui/download/BoundingBoxSelection.java
>>> 219:                setErrorMessage(tfLatValue,tr("The string ''{0}''
>>> isn''t a valid double value.", tfLatValue.getText()));
>>> 251:                setErrorMessage(tfLonValue,tr("The string ''{0}''
>>> isn''t a valid double value.", tfLonValue.getText()));
>>>
>>> src/org/openstreetmap/josm/gui/widgets/BoundingBoxSelectionPanel.java
>>> 160:                feedbackInvalid(tr("The string ''{0}'' isn''t a
>>> valid double value.", getComponent().getText()));
>>> 200:                feedbackInvalid(tr("The string ''{0}'' isn''t a
>>> valid double value.", getComponent().getText()));
>>>
>>> src/org/openstreetmap/josm/gui/dialogs/changeset/query/AdvancedChangesetQueryPanel.java
>>> 533:                    throw new IllegalStateException(tr("Current
>>> value ''{0}'' for user ID isn''t valid", tfUid.getText()));
>>>
>>>
>>>        
>>>> Forthermore I find sometimes american english (e.g. 'initialize').
>>>> Wasn't the overall policy to use british english?
>>>>
>>>>          
>>> I thought the source default was en_US since if it was en_GB the
>>> existing en_GB translation would be pointless (and we'd need a en_US
>>> one).
>>>        
> Makes sense. The "only british english" policy is for the OSM tags, I
> think.
>
>    
>>>> And finally sometimes I find XHTML style end tags in translated texts
>>>> (e.g. '<br />' instead of'<br>'). By now I haven't found any in the
>>>> source. Is it ok to use them or should these be fixed?
>>>>
>>>>          
>>> The HTML is rendered by some internal Java stuff, both of those tags
>>> work just as well when fed to it so I don't think it needs to be fixed
>>> either way.
>>>        
>
> Thank you both for the quit response!
>
>
> Regards
> Andre
>
>
>
>