Escaping colons and equal-signs

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Escaping colons and equal-signs

David Farning
I was wondering if there is a reason that some translators escape colons
and equal-signs ie. \: and \= in some languages.  I could not find any
references to these escape codes, but I have only been search English
references.

thanks
-dtf

_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Escaping colons and equal-signs

Ognyan Kulev
David Farning wrote:
> I was wondering if there is a reason that some translators escape colons
> and equal-signs ie. \: and \= in some languages.  I could not find any
> references to these escape codes, but I have only been search English
> references.

These escapes are for .properties files.
http://bugs.wordforge.org/show_bug.cgi?id=12 has more information.

Regards,
ogi

_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Escaping colons and equal-signs

David Farning
On Tue, 2005-11-15 at 20:33 +0200, Ognyan Kulev wrote:

> David Farning wrote:
> > I was wondering if there is a reason that some translators escape colons
> > and equal-signs ie. \: and \= in some languages.  I could not find any
> > references to these escape codes, but I have only been search English
> > references.
>
> These escapes are for .properties files.
> http://bugs.wordforge.org/show_bug.cgi?id=12 has more information.
>
> Regards,
> ogi
>
Thanks,
  I found that link this morning but still don't understand why they are
escaped in the .properties file in the first place.

If these escapes are not necessary, we should set a standard that tools
not escape them unnecessarily.

thanks
-dtf

_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Escaping colons and equal-signs

Ognyan Kulev
David Farning wrote:
> If these escapes are not necessary, we should set a standard that tools
> not escape them unnecessarily.

"Should"?  Why?  This would make such files to not confirm the Java
.properties spec.  They would be no longer Java .properties files but
Mozilla .properties files.

Regards,
ogi
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Escaping colons and equal-signs

David Farning
On Tue, 2005-11-15 at 21:11 +0200, Ognyan Kulev wrote:
> David Farning wrote:
> > If these escapes are not necessary, we should set a standard that
tools
> > not escape them unnecessarily.
>
> "Should"?  Why?  This would make such files to not confirm the Java
> .properties spec.  They would be no longer Java .properties files but
> Mozilla .properties files.
>
> Regards,
> ogi
Ok, so the /: and /= are there in order to conform to java .properties
spec(I've never work with java .properties files.) I didn't realize
that.

I'll read up on java .properties files.

If we want to meet java specs then all colons and equal-signs should be
escaped.  Escaping some but not all is difficult to deal with
downstream.



thanks
-dtf

_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Escaping colons and equal-signs

Axel Hecht
In reply to this post by Ognyan Kulev
David Farning wrote:

> On Tue, 2005-11-15 at 21:11 +0200, Ognyan Kulev wrote:
>> David Farning wrote:
>>> If these escapes are not necessary, we should set a standard that
> tools
>>> not escape them unnecessarily.
>> "Should"?  Why?  This would make such files to not confirm the Java
>> .properties spec.  They would be no longer Java .properties files but
>> Mozilla .properties files.
>>
>> Regards,
>> ogi
> Ok, so the /: and /= are there in order to conform to java .properties
> spec(I've never work with java .properties files.) I didn't realize
> that.
>
> I'll read up on java .properties files.
>
> If we want to meet java specs then all colons and equal-signs should be
> escaped.  Escaping some but not all is difficult to deal with
> downstream.

I'd really welcome if you'd settle with the fact that l10n is not
supposed to make tools happy.

If your code has a problem, make a release note for it, and if a locale
wants to use it, they need to deal with it.

Being not capable of handling whatever works is not going to make your
tool the tool of choice.

Axel
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Escaping colons and equal-signs

David Farning
On Tue, 2005-11-15 at 21:57 +0100, Axel Hecht wrote:
> David Farning wrote:
> > On Tue, 2005-11-15 at 21:11 +0200, Ognyan Kulev wrote:
> >> David Farning wrote:
> >>> If these escapes are not necessary, we should set a standard that
> > tools
> >>> not escape them unnecessarily.
> >> "Should"?  Why?  This would make such files to not confirm the
Java
> >> .properties spec.  They would be no longer Java .properties files
but
> >> Mozilla .properties files.
> >>
> >> Regards,
> >> ogi
> > Ok, so the /: and /= are there in order to conform to
java .properties
> > spec(I've never work with java .properties files.) I didn't realize
> > that.
> >
> > I'll read up on java .properties files.
> >
> > If we want to meet java specs then all colons and equal-signs should
be
> > escaped.  Escaping some but not all is difficult to deal with
> > downstream.
>
> I'd really welcome if you'd settle with the fact that l10n is not
> supposed to make tools happy.
Why not?  The better the translation tools the more translators there
will be.  One often hears that the value of a network is equal to the
square of it's nodes.
 

> If your code has a problem, make a release note for it, and if a
locale
> wants to use it, they need to deal with it.
Why not deal with these issues on a project level by presenting
guidelines in the form of recommended standards or styles for output?
So the each local doesn't have to reinvent the wheel.


> Being not capable of handling whatever works is not going to make
your
> tool the tool of choice.
The biggest problem that I see is the fact that mozilla stores l10n
information in cvs. This means that format of the data becomes important
when updating the cvs.  I understand why mozilla made the decision to go
with l10n date in the cvs. All I am looking for are recommend guidelines
for tool developers to use when
outputting data.

thanks
-dtf


_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n
Reply | Threaded
Open this post in threaded view
|

Re: Escaping colons and equal-signs

Robert Kaiser
In reply to this post by Axel Hecht
David Farning schrieb:
> Why not?  The better the translation tools the more translators there
> will be.  One often hears that the value of a network is equal to the
> square of it's nodes.

Noone is against good tools, but every good tool has to be tolerant
about its input (so on the input side, you should try supporting even
slight errors in the files), and follow a "good practice" model on the
output side. So as the .properties is a standard we adopted from Java,
and DTD is an XML standard, it would be "good practice" for your tool to
follow those standards for output.

We will not inforce those "good practice" styles though, as long as the
mozilla apps can deal with the produced files. It's more important for
us to have well-working software available in many languages than to
prohibit someone's work just because it doesn't follow a particular
"good practice" model.

Don't get me wrong, tools are a nice thing to have (and I myself love
using MT despite its obvious flaws), but the "source L10n" approach
really cares about the source code files in CVS, and the basic thought
is people editing the en-US files by hand - and this should work easily
(even if most people maybe won't do it). If now a tool comes into the
game, it should basically care to help the localizer in doing that
editing work and produce the same output he would in doing so.

Robert Kaiser
_______________________________________________
mozilla-l10n mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-l10n