[sip-comm-dev] French language resources

#1

Hi,

While working on the french language resources file, every single
quote is doubled. I first thought that because it's needed but when
running the program, there still doubled.
I've check the API (java 1.5) and nothing is said about this.

Is there a reason for thoses doubled singles quotes ?

Examples :
- {0} est en train d''écrire un message
- Liste d''appels

···

+
Damien

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

#2

Hi Damien,

The current service handling translations is the ResourceManagementService
which uses the MessageFormat class to build messages. The documentation
about this class (
http://java.sun.com/j2se/1.5.0/docs/api/java/text/MessageFormat.html) is
very confusing about quotes but my understanding is that we have to
duplicate any single quotes in translations as long as we use the default
formatter parameters. If it's not working to you, well we obviously has
something to fix here.

Hope that helps,

Ben

···

2008/11/27 Damien Roth <damien.roth@gmail.com>

Hi,

While working on the french language resources file, every single
quote is doubled. I first thought that because it's needed but when
running the program, there still doubled.
I've check the API (java 1.5) and nothing is said about this.

Is there a reason for thoses doubled singles quotes ?

Examples :
- {0} est en train d''écrire un message
- Liste d''appels

+
Damien

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

#3

Hi Benoit,

Thanks for your help. In fact, the ResourceManagementService doesn't
use this class but the Messages class in the GUI.
The major problem is the MessageFormat class is only used when the
string as parameters. (I think that using this class for every string
isn't good for performances)

Every string in the file use the MessageFormat syntax but not all pass
through the class. That's why French users see doubled single quotes.
The problem might also appears for to any language that use the single
quote.

I will update the documentation and remove all the unnecessary single
quotes in the french language file.

Cheers

Damien

···

2008/11/28 Benoit Pradelle <b.pradelle@gmail.com>:

Hi Damien,

The current service handling translations is the ResourceManagementService
which uses the MessageFormat class to build messages. The documentation
about this class
(http://java.sun.com/j2se/1.5.0/docs/api/java/text/MessageFormat.html) is
very confusing about quotes but my understanding is that we have to
duplicate any single quotes in translations as long as we use the default
formatter parameters. If it's not working to you, well we obviously has
something to fix here.

Hope that helps,

Ben

2008/11/27 Damien Roth <damien.roth@gmail.com>

Hi,

While working on the french language resources file, every single
quote is doubled. I first thought that because it's needed but when
running the program, there still doubled.
I've check the API (java 1.5) and nothing is said about this.

Is there a reason for thoses doubled singles quotes ?

Examples :
- {0} est en train d''écrire un message
- Liste d''appels

+
Damien

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Damien ROTH
Programmeur n.m : Celui qui résout un problème que vous n'aviez pas,
d'une façon que vous ne comprenez pas.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

#4

Hi Damien,

Thanks for these clarifications, it seems to me that it will be complex to
differentiate the cases of a translation containing a parameter and the case
of a parameter-less translation. Perhaps a better way to handle that would
be to not take single quotes into consideration when handling parametrized
translations leading the translators to not having to protect all (or worse,
some) of the single quotes.

What do you think?

Ben

···

2008/11/29 Damien Roth <damien.roth@gmail.com>

Hi Benoit,

Thanks for your help. In fact, the ResourceManagementService doesn't
use this class but the Messages class in the GUI.
The major problem is the MessageFormat class is only used when the
string as parameters. (I think that using this class for every string
isn't good for performances)

Every string in the file use the MessageFormat syntax but not all pass
through the class. That's why French users see doubled single quotes.
The problem might also appears for to any language that use the single
quote.

I will update the documentation and remove all the unnecessary single
quotes in the french language file.

Cheers

Damien

2008/11/28 Benoit Pradelle <b.pradelle@gmail.com>:
> Hi Damien,
>
> The current service handling translations is the
ResourceManagementService
> which uses the MessageFormat class to build messages. The documentation
> about this class
> (http://java.sun.com/j2se/1.5.0/docs/api/java/text/MessageFormat.html)
is
> very confusing about quotes but my understanding is that we have to
> duplicate any single quotes in translations as long as we use the default
> formatter parameters. If it's not working to you, well we obviously has
> something to fix here.
>
> Hope that helps,
>
> Ben
>
> 2008/11/27 Damien Roth <damien.roth@gmail.com>
>>
>> Hi,
>>
>> While working on the french language resources file, every single
>> quote is doubled. I first thought that because it's needed but when
>> running the program, there still doubled.
>> I've check the API (java 1.5) and nothing is said about this.
>>
>> Is there a reason for thoses doubled singles quotes ?
>>
>> Examples :
>> - {0} est en train d''écrire un message
>> - Liste d''appels
>>
>>
>> +
>> Damien
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
>> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>>
>
>

--
Damien ROTH
Programmeur n.m : Celui qui résout un problème que vous n'aviez pas,
d'une façon que vous ne comprenez pas.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

#5

Hi,

Thanks for these clarifications, it seems to me that it will be complex to differentiate the cases of a translation containing a parameter and the case of a parameter-less translation.

I don't think so, it's really easy to recognize a translation with
parameters. The parameters are just place holders like {0}, {1}, ...
So developers and translators should just apply the rule : double the
single quotes if the translation has parameters.

Perhaps a better way to handle that would be to not take single quotes into consideration when handling parametrized translations leading the translators to not having to protect all (or worse, some) of the single quotes.

I've check the api of the MessageFormat class and it's not possible to
ignore single quotes.

A quick search in the english file show me that there is also single
quotes bugs. Before the launching of the v1, we should review all of
the translations (there is a lot of missing elements).

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

#6

Hi,

I understand that it's easy to differentiate a translation with or without
any parameter but I think that we should do all we can to ease the work of
translators. Imagine a beginner translator that want to help us by creating
or enhancing a translation. If he had to respect some really boring rules
and think for each translation if he needs to protect the quotes or not, he
risks to be quickly bored and to simply abandon the translation. Moreover
I'm sure that we don't want to spend time in fixing bugs in translation and
a rule like this will probably be sooner or later be a source of bugs.

And if the api doesn't allow us to filter the quotes, why don't simply parse
the String and automatically protect the quotes in it? If we do it
efficiently the translator would not have to care about protecting or not
the quotes in the String.

What do you all think ?

Ben

···

2008/11/29 Damien Roth <damien.roth@gmail.com>

Hi,

> Thanks for these clarifications, it seems to me that it will be complex
to differentiate the cases of a translation containing a parameter and the
case of a parameter-less translation.

I don't think so, it's really easy to recognize a translation with
parameters. The parameters are just place holders like {0}, {1}, ...
So developers and translators should just apply the rule : double the
single quotes if the translation has parameters.

> Perhaps a better way to handle that would be to not take single quotes
into consideration when handling parametrized translations leading the
translators to not having to protect all (or worse, some) of the single
quotes.

I've check the api of the MessageFormat class and it's not possible to
ignore single quotes.

A quick search in the english file show me that there is also single
quotes bugs. Before the launching of the v1, we should review all of
the translations (there is a lot of missing elements).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

#7

Hi,

I understand that it's easy to differentiate a translation with or without
any parameter but I think that we should do all we can to ease the work of
translators. Imagine a beginner translator that want to help us by creating
or enhancing a translation. If he had to respect some really boring rules
and think for each translation if he needs to protect the quotes or not, he
risks to be quickly bored and to simply abandon the translation. Moreover
I'm sure that we don't want to spend time in fixing bugs in translation and
a rule like this will probably be sooner or later be a source of bugs.

Sure. We shouldn't ask translators to work around what seems a bug in SC
(ok in MessageFormat but from a translator's point of view, it's still a
bug in SC). Moreover, it wouldn't be future-proof (imagine we drop
MessageFormat for something less weird).

And if the api doesn't allow us to filter the quotes, why don't simply parse
the String and automatically protect the quotes in it? If we do it
efficiently the translator would not have to care about protecting or not
the quotes in the String.

What do you all think ?

I vote for pain-free translating.

Sidenote: Did the guys at Sun ever think that one could use a single
quote in a class designed *for translations*? There is a bug marked as
fixed [0] related to this, but I fear the only thing that was fixed was
the documentation now explaining the bug.

[0] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4293229

Cheers,

···

On Sat, Nov 29, 2008 at 05:37:04PM -0500, Benoit Pradelle wrote:

--
Sébastien Mazy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

#8

Hi,

I absolutely agree that we need to simplify the work of translators and I like the idea of parsing the String.

Cheers,
Yana

Sébastien Mazy wrote:

···

Hi,

On Sat, Nov 29, 2008 at 05:37:04PM -0500, Benoit Pradelle wrote:

I understand that it's easy to differentiate a translation with or without
any parameter but I think that we should do all we can to ease the work of
translators. Imagine a beginner translator that want to help us by creating
or enhancing a translation. If he had to respect some really boring rules
and think for each translation if he needs to protect the quotes or not, he
risks to be quickly bored and to simply abandon the translation. Moreover
I'm sure that we don't want to spend time in fixing bugs in translation and
a rule like this will probably be sooner or later be a source of bugs.

Sure. We shouldn't ask translators to work around what seems a bug in SC
(ok in MessageFormat but from a translator's point of view, it's still a
bug in SC). Moreover, it wouldn't be future-proof (imagine we drop
MessageFormat for something less weird).

And if the api doesn't allow us to filter the quotes, why don't simply parse
the String and automatically protect the quotes in it? If we do it
efficiently the translator would not have to care about protecting or not
the quotes in the String.

What do you all think ?

I vote for pain-free translating.

Sidenote: Did the guys at Sun ever think that one could use a single
quote in a class designed *for translations*? There is a bug marked as
fixed [0] related to this, but I fear the only thing that was fixed was
the documentation now explaining the bug.

[0] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4293229

Cheers,

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

#9

Hi,

The best way to simplify their work is to automatically escape the two
characters.

The single quote is very simple, but the problem is with {. It's used
as place holder so we can't just add a single quote before. I think
its possible with a complex regular expression to differentiate the
two cases.

If someone know how to write this regexp ?

I just commit a little patch to manage the single quotes. I will take
a look to the languages files later.

Bye

Damien

···

2008/11/30 Yana Stamcheva <yana@sip-communicator.org>:

Hi,

I absolutely agree that we need to simplify the work of translators and I
like the idea of parsing the String.

Cheers,
Yana

Sébastien Mazy wrote:

Hi,

On Sat, Nov 29, 2008 at 05:37:04PM -0500, Benoit Pradelle wrote:

I understand that it's easy to differentiate a translation with or
without
any parameter but I think that we should do all we can to ease the work
of
translators. Imagine a beginner translator that want to help us by
creating
or enhancing a translation. If he had to respect some really boring rules
and think for each translation if he needs to protect the quotes or not,
he
risks to be quickly bored and to simply abandon the translation. Moreover
I'm sure that we don't want to spend time in fixing bugs in translation
and
a rule like this will probably be sooner or later be a source of bugs.

Sure. We shouldn't ask translators to work around what seems a bug in SC
(ok in MessageFormat but from a translator's point of view, it's still a
bug in SC). Moreover, it wouldn't be future-proof (imagine we drop
MessageFormat for something less weird).

And if the api doesn't allow us to filter the quotes, why don't simply
parse
the String and automatically protect the quotes in it? If we do it
efficiently the translator would not have to care about protecting or not
the quotes in the String.

What do you all think ?

I vote for pain-free translating.

Sidenote: Did the guys at Sun ever think that one could use a single
quote in a class designed *for translations*? There is a bug marked as
fixed [0] related to this, but I fear the only thing that was fixed was
the documentation now explaining the bug.

[0] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4293229

Cheers,

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Damien ROTH
Programmeur n.m : Celui qui résout un problème que vous n'aviez pas,
d'une façon que vous ne comprenez pas.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net