[sip-comm-dev] Potentially major flaw in i18n resources.properties


#1

Hi, me again...

I stumbled into a bug in the i18n properties files in resources\languages. The new whiteboard section is reusing key names that have already been used, such as 'file' and 'about' This causes a potential problem when net.java.sip.communicator.impl.gui.i18n.Messages reads the translation values. If there is more than one key with the same name, it will read the value of the last key in the file.

This has actually led to the disappearance of the keyboard alts (the code calls them mnemonics) for the main menus on the main SC screen for 'File' and 'Help'. This is because the first listing correctly has file=&File but the whiteboard keys replace that with file=File. (Note the loss of the &). There are other conflicts as well, I haven't made a complete list yet.

Key names shouldn't be re-used like that, perhaps all the whiteboard keys should be renamed with a 'whiteboard-' prefix? Either that or they should just use the same i18n keys that are alraedy defined. (I haven't used the white board so I don't know what's going on here).

We have the same potential to have other conflicts elsewhere (and some may even exist) unless there is a naming convention of some sort for i18n keys. My suggestion is that anything that isn't global or universal should have some sort of prefix related to its plugin/service/etc.

Alan

···

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


#2

Hey Alan,

Yes, that's a good point. I even remember actually discussing the
unification of resource strings with someone but I guess no one gout
around to it.

Interested in proposing a patch?

Emil

···

On Tue, Jul 29, 2008 at 8:21 PM, Alan C Kelly <akelly7@gmu.edu> wrote:

Hi, me again...

I stumbled into a bug in the i18n properties files in resources\languages. The new whiteboard section is reusing key names that have already been used, such as 'file' and 'about' This causes a potential problem when net.java.sip.communicator.impl.gui.i18n.Messages reads the translation values. If there is more than one key with the same name, it will read the value of the last key in the file.

This has actually led to the disappearance of the keyboard alts (the code calls them mnemonics) for the main menus on the main SC screen for 'File' and 'Help'. This is because the first listing correctly has file=&File but the whiteboard keys replace that with file=File. (Note the loss of the &). There are other conflicts as well, I haven't made a complete list yet.

Key names shouldn't be re-used like that, perhaps all the whiteboard keys should be renamed with a 'whiteboard-' prefix? Either that or they should just use the same i18n keys that are alraedy defined. (I haven't used the white board so I don't know what's going on here).

We have the same potential to have other conflicts elsewhere (and some may even exist) unless there is a naming convention of some sort for i18n keys. My suggestion is that anything that isn't global or universal should have some sort of prefix related to its plugin/service/etc.

Alan

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


#3

Oops, hit "Send" too quickly. What I wanted to add was that we could
agree on using naming conventions similar to that in the configuration
service which would give us something like:

net.java.sip.communicator.[service|impl|plugin].bundlename.RESOURCE_NAME

In this case we can actually even skip the "net.java.sip.communicator"
prefix and only keep the part that would change from one package to
the next. This way the whiteboard strings for example would have the
following form:

plugin.whiteboard.FILE=&File (The upper case would be nice to have but
it's not essential)

How does this sound?

Cheers
Emil

···

On Wed, Jul 30, 2008 at 2:52 AM, Emil Ivov <emcho@sip-communicator.org> wrote:

Hey Alan,

Yes, that's a good point. I even remember actually discussing the
unification of resource strings with someone but I guess no one gout
around to it.

Interested in proposing a patch?

Emil

On Tue, Jul 29, 2008 at 8:21 PM, Alan C Kelly <akelly7@gmu.edu> wrote:

Hi, me again...

I stumbled into a bug in the i18n properties files in resources\languages. The new whiteboard section is reusing key names that have already been used, such as 'file' and 'about' This causes a potential problem when net.java.sip.communicator.impl.gui.i18n.Messages reads the translation values. If there is more than one key with the same name, it will read the value of the last key in the file.

This has actually led to the disappearance of the keyboard alts (the code calls them mnemonics) for the main menus on the main SC screen for 'File' and 'Help'. This is because the first listing correctly has file=&File but the whiteboard keys replace that with file=File. (Note the loss of the &). There are other conflicts as well, I haven't made a complete list yet.

Key names shouldn't be re-used like that, perhaps all the whiteboard keys should be renamed with a 'whiteboard-' prefix? Either that or they should just use the same i18n keys that are alraedy defined. (I haven't used the white board so I don't know what's going on here).

We have the same potential to have other conflicts elsewhere (and some may even exist) unless there is a naming convention of some sort for i18n keys. My suggestion is that anything that isn't global or universal should have some sort of prefix related to its plugin/service/etc.

Alan

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


#4

Emil,

That sounds like a nice solution. That's going to be a lot of changes to
make. I'm actually going to be going out of town in a couple of days so I'm
not likely to be able to tackle this before I leave. If it's still an issue
when I get back late next week, I'll try working with it.

Also, there are some values that would probably be global to all of SC, what
would we call those? Just leave off the prefix? For example, how many
listings will we really need for the word "Help"? It seems a little
redundant.

Alan

···

-----Original Message-----

From: Emil Ivov [mailto:emcho@sip-communicator.org]

Sent: Tuesday, July 29, 2008 9:00 PM
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Potentially major flaw in i18n
resources.properties

Oops, hit "Send" too quickly. What I wanted to add was that we could agree
on using naming conventions similar to that in the configuration service
which would give us something like:

net.java.sip.communicator.[service|impl|plugin].bundlename.RESOURCE_NAME

In this case we can actually even skip the "net.java.sip.communicator"
prefix and only keep the part that would change from one package to the
next. This way the whiteboard strings for example would have the following
form:

plugin.whiteboard.FILE=&File (The upper case would be nice to have but it's
not essential)

How does this sound?

Cheers
Emil

On Wed, Jul 30, 2008 at 2:52 AM, Emil Ivov <emcho@sip-communicator.org> wrote:

Hey Alan,

Yes, that's a good point. I even remember actually discussing the
unification of resource strings with someone but I guess no one gout
around to it.

Interested in proposing a patch?

Emil

On Tue, Jul 29, 2008 at 8:21 PM, Alan C Kelly <akelly7@gmu.edu> wrote:

Hi, me again...

I stumbled into a bug in the i18n properties files in

resources\languages. The new whiteboard section is reusing key names that
have already been used, such as 'file' and 'about' This causes a potential
problem when net.java.sip.communicator.impl.gui.i18n.Messages reads the
translation values. If there is more than one key with the same name, it
will read the value of the last key in the file.

This has actually led to the disappearance of the keyboard alts (the code

calls them mnemonics) for the main menus on the main SC screen for 'File'
and 'Help'. This is because the first listing correctly has file=&File but
the whiteboard keys replace that with file=File. (Note the loss of the &).
There are other conflicts as well, I haven't made a complete list yet.

Key names shouldn't be re-used like that, perhaps all the whiteboard keys

should be renamed with a 'whiteboard-' prefix? Either that or they should
just use the same i18n keys that are alraedy defined. (I haven't used the
white board so I don't know what's going on here).

We have the same potential to have other conflicts elsewhere (and some

may even exist) unless there is a naming convention of some sort for i18n
keys. My suggestion is that anything that isn't global or universal should
have some sort of prefix related to its plugin/service/etc.

Alan

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

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

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


#5

Hey Alan,

Emil,

That sounds like a nice solution. That's going to be a lot of changes to
make. I'm actually going to be going out of town in a couple of days so I'm
not likely to be able to tackle this before I leave. If it's still an issue
when I get back late next week, I'll try working with it.

If you'd like to do it then we'll make sure it stays open for you.

Also, there are some values that would probably be global to all of SC, what
would we call those? Just leave off the prefix? For example, how many
listings will we really need for the word "Help"? It seems a little
redundant.

Good point. Guess we could follow the development convention here and
place "public" keys in "service.gui". The idea is that everything
that's prefixed by service may be accessed in an inter-bundle and
should remain stable.

What do you think?

Emil

···

On Wed, Jul 30, 2008 at 5:11 AM, Alan Kelly <akelly7@gmu.edu> wrote:

Alan

-----Original Message-----
From: Emil Ivov [mailto:emcho@sip-communicator.org]
Sent: Tuesday, July 29, 2008 9:00 PM
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Potentially major flaw in i18n
resources.properties

Oops, hit "Send" too quickly. What I wanted to add was that we could agree
on using naming conventions similar to that in the configuration service
which would give us something like:

net.java.sip.communicator.[service|impl|plugin].bundlename.RESOURCE_NAME

In this case we can actually even skip the "net.java.sip.communicator"
prefix and only keep the part that would change from one package to the
next. This way the whiteboard strings for example would have the following
form:

plugin.whiteboard.FILE=&File (The upper case would be nice to have but it's
not essential)

How does this sound?

Cheers
Emil

On Wed, Jul 30, 2008 at 2:52 AM, Emil Ivov <emcho@sip-communicator.org> > wrote:

Hey Alan,

Yes, that's a good point. I even remember actually discussing the
unification of resource strings with someone but I guess no one gout
around to it.

Interested in proposing a patch?

Emil

On Tue, Jul 29, 2008 at 8:21 PM, Alan C Kelly <akelly7@gmu.edu> wrote:

Hi, me again...

I stumbled into a bug in the i18n properties files in

resources\languages. The new whiteboard section is reusing key names that
have already been used, such as 'file' and 'about' This causes a potential
problem when net.java.sip.communicator.impl.gui.i18n.Messages reads the
translation values. If there is more than one key with the same name, it
will read the value of the last key in the file.

This has actually led to the disappearance of the keyboard alts (the code

calls them mnemonics) for the main menus on the main SC screen for 'File'
and 'Help'. This is because the first listing correctly has file=&File but
the whiteboard keys replace that with file=File. (Note the loss of the &).
There are other conflicts as well, I haven't made a complete list yet.

Key names shouldn't be re-used like that, perhaps all the whiteboard keys

should be renamed with a 'whiteboard-' prefix? Either that or they should
just use the same i18n keys that are alraedy defined. (I haven't used the
white board so I don't know what's going on here).

We have the same potential to have other conflicts elsewhere (and some

may even exist) unless there is a naming convention of some sort for i18n
keys. My suggestion is that anything that isn't global or universal should
have some sort of prefix related to its plugin/service/etc.

Alan

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

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

---------------------------------------------------------------------
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,

Also, there are some values that would probably be global to all of SC, what
would we call those? Just leave off the prefix? For example, how many
listings will we really need for the word "Help"? It seems a little
redundant.

Good point. Guess we could follow the development convention here and
place "public" keys in "service.gui". The idea is that everything
that's prefixed by service may be accessed in an inter-bundle and
should remain stable.

What do you think?

I like this idea. But I think for the public keys we should avoid
using the prefix service. Most of these keys will be for the GUI, so I
propose this denomination, examples :

for the next button : gui.next=Next
for a menu item : gui.menu.file=&File

We can also, do like Emil said and put the last element of the key in uppercase.

Bye

Damien

···

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


#7

Sounds good to me, I'll start working on it.

···

----- Original Message -----

From: Emil Ivov <emcho@sip-communicator.org>

Date: Wednesday, July 30, 2008 5:09 am
Subject: Re: [sip-comm-dev] Potentially major flaw in i18n resources.properties

Hey Alan,

On Wed, Jul 30, 2008 at 5:11 AM, Alan Kelly <akelly7@gmu.edu> wrote:
> Emil,
>
> That sounds like a nice solution. That's going to be a lot of
changes to
> make. I'm actually going to be going out of town in a couple of
days so I'm
> not likely to be able to tackle this before I leave. If it's
still an issue
> when I get back late next week, I'll try working with it.

If you'd like to do it then we'll make sure it stays open for you.

> Also, there are some values that would probably be global to all
of SC, what
> would we call those? Just leave off the prefix? For example, how
> listings will we really need for the word "Help"? It seems a
> redundant.

Good point. Guess we could follow the development convention here and
place "public" keys in "service.gui". The idea is that everything
that's prefixed by service may be accessed in an inter-bundle and
should remain stable.

What do you think?

Emil
>
> Alan
>
> -----Original Message-----
> From: Emil Ivov [mailto:emcho@sip-communicator.org]
> Sent: Tuesday, July 29, 2008 9:00 PM
> To: dev@sip-communicator.dev.java.net
> Subject: Re: [sip-comm-dev] Potentially major flaw in i18n
> resources.properties
>
> Oops, hit "Send" too quickly. What I wanted to add was that we
could agree
> on using naming conventions similar to that in the configuration
> which would give us something like:
>
>
net.java.sip.communicator.[service|impl|plugin].bundlename.RESOURCE_NAME>
> In this case we can actually even skip the
"net.java.sip.communicator"> prefix and only keep the part that
would change from one package to the
> next. This way the whiteboard strings for example would have the
> form:
>
> plugin.whiteboard.FILE=&File (The upper case would be nice to
have but it's
> not essential)
>
> How does this sound?
>
> Cheers
> Emil
>
> On Wed, Jul 30, 2008 at 2:52 AM, Emil Ivov <emcho@sip- > communicator.org>> wrote:
>> Hey Alan,
>>
>> Yes, that's a good point. I even remember actually discussing the
>> unification of resource strings with someone but I guess no one
>> around to it.
>>
>> Interested in proposing a patch?
>>
>> Emil
>>
>> On Tue, Jul 29, 2008 at 8:21 PM, Alan C Kelly <akelly7@gmu.edu>
wrote:>>> Hi, me again...
>>>
>>> I stumbled into a bug in the i18n properties files in
> resources\languages. The new whiteboard section is reusing key
names that
> have already been used, such as 'file' and 'about' This causes a
> problem when
net.java.sip.communicator.impl.gui.i18n.Messages reads the
> translation values. If there is more than one key with the same
name, it
> will read the value of the last key in the file.
>>>
>>> This has actually led to the disappearance of the keyboard
alts (the code
> calls them mnemonics) for the main menus on the main SC screen
for 'File'
> and 'Help'. This is because the first listing correctly has
file=&File but
> the whiteboard keys replace that with file=File. (Note the loss
of the &).
> There are other conflicts as well, I haven't made a complete
list yet.
>>>
>>> Key names shouldn't be re-used like that, perhaps all the
whiteboard keys
> should be renamed with a 'whiteboard-' prefix? Either that or
they should
> just use the same i18n keys that are alraedy defined. (I haven't
used the
> white board so I don't know what's going on here).
>>>
>>> We have the same potential to have other conflicts elsewhere
(and some
> may even exist) unless there is a naming convention of some sort
for i18n
> keys. My suggestion is that anything that isn't global or
universal should
> have some sort of prefix related to its plugin/service/etc.
>>>
>>> Alan
>>>
>>> ---------------------------------------------------------------
------
>>> To unsubscribe, e-mail: dev-unsubscribe@sip-
communicator.dev.java.net>>> For additional commands, e-mail:
>>> dev-help@sip-communicator.dev.java.net
>>>
>>>
>>
>
> -----------------------------------------------------------------
----
> To unsubscribe, e-mail: dev-unsubscribe@sip-
communicator.dev.java.net> For additional commands, e-mail: dev-
help@sip-communicator.dev.java.net
>
>
> -----------------------------------------------------------------
----
> To unsubscribe, e-mail: dev-unsubscribe@sip-
communicator.dev.java.net> For additional commands, e-mail: dev-
help@sip-communicator.dev.java.net
>
>

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

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


#8

I like this idea. But I think for the public keys we should avoid
using the prefix service. Most of these keys will be for the GUI, so I
propose this denomination, examples :

for the next button : gui.next=Next
for a menu item : gui.menu.file=&File

The point of using the service prefix is to distinguish between
"public" and "private" keys.

It's pretty much the same logic as with bundles that are supposed to
only access classes that belong to the "service" hierarchy. This way a
plug-in developer who needs to access keys already defined somewhere
else would know that "service.gui.menu.FILE" is ok to use while
"impl.gui.menu.SOME_OTHER_KEY" is likely to change without notice or
to simply disappear. Of course we could use the impl prefix for
"private" keys and no prefix for the "public" ones but as I already
mentioned the idea was to mimic our programming architecture.

Anyways, I don't think the exact prefix is all that important as long
as it allows to know which keys are "inter-bundle" so if you guys
prefer not to have service, then I don't really mind.

Cheers
Emil

···

On Wed, Jul 30, 2008 at 12:09 PM, Damien Roth <damien.roth@gmail.com> wrote:

We can also, do like Emil said and put the last element of the key in uppercase.

Bye

Damien

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


#9

Update on the changes to resources.properties:

Attached is the newly organized properties file, with the bundle prefixes added. I am sending this out as a preview of the changes Emil and I agreed upon. Any comments are welcome.

I still have to complete the lengthy chore of adding the prefixes every place getI18NString() is called in the code. When this is finished I will submit a patch.

Unfortunately these changes mean that the various translation files will have to be redone as well.

Alan

resources.properties (36 KB)

···

----- Original Message -----

From: Alan C Kelly <akelly7@gmu.edu>

Date: Friday, August 8, 2008 12:19 pm
Subject: Re: [sip-comm-dev] Potentially major flaw in i18n resources.properties

Sounds good to me, I'll start working on it.

----- Original Message -----
From: Emil Ivov <emcho@sip-communicator.org>
Date: Wednesday, July 30, 2008 5:09 am
Subject: Re: [sip-comm-dev] Potentially major flaw in i18n
resources.properties
> Hey Alan,
>
> On Wed, Jul 30, 2008 at 5:11 AM, Alan Kelly <akelly7@gmu.edu> wrote:
> > Emil,
> >
> > That sounds like a nice solution. That's going to be a lot of
> changes to
> > make. I'm actually going to be going out of town in a couple
of
> days so I'm
> > not likely to be able to tackle this before I leave. If it's
> still an issue
> > when I get back late next week, I'll try working with it.
>
> If you'd like to do it then we'll make sure it stays open for you.
>
> > Also, there are some values that would probably be global to
all
> of SC, what
> > would we call those? Just leave off the prefix? For example,
how
> > listings will we really need for the word "Help"? It seems
a
> > redundant.
>
> Good point. Guess we could follow the development convention
here and
> place "public" keys in "service.gui". The idea is that everything
> that's prefixed by service may be accessed in an inter-bundle and
> should remain stable.
>
> What do you think?
>
> Emil
> >
> > Alan
> >
> > -----Original Message-----
> > From: Emil Ivov [mailto:emcho@sip-communicator.org]
> > Sent: Tuesday, July 29, 2008 9:00 PM
> > To: dev@sip-communicator.dev.java.net
> > Subject: Re: [sip-comm-dev] Potentially major flaw in i18n
> > resources.properties
> >
> > Oops, hit "Send" too quickly. What I wanted to add was that we
> could agree
> > on using naming conventions similar to that in the
configuration
> > which would give us something like:
> >
> >
>
net.java.sip.communicator.[service|impl|plugin].bundlename.RESOURCE_NAME>> > In this case we can actually even skip the
> "net.java.sip.communicator"> prefix and only keep the part that
> would change from one package to the
> > next. This way the whiteboard strings for example would have
the
> > form:
> >
> > plugin.whiteboard.FILE=&File (The upper case would be nice to
> have but it's
> > not essential)
> >
> > How does this sound?
> >
> > Cheers
> > Emil
> >
> > On Wed, Jul 30, 2008 at 2:52 AM, Emil Ivov <emcho@sip- > > communicator.org>> wrote:
> >> Hey Alan,
> >>
> >> Yes, that's a good point. I even remember actually discussing the
> >> unification of resource strings with someone but I guess no
one
> >> around to it.
> >>
> >> Interested in proposing a patch?
> >>
> >> Emil
> >>
> >> On Tue, Jul 29, 2008 at 8:21 PM, Alan C Kelly
<akelly7@gmu.edu>
> wrote:>>> Hi, me again...
> >>>
> >>> I stumbled into a bug in the i18n properties files in
> > resources\languages. The new whiteboard section is reusing key
> names that
> > have already been used, such as 'file' and 'about' This causes
a
> > problem when
> net.java.sip.communicator.impl.gui.i18n.Messages reads the
> > translation values. If there is more than one key with the
same
> name, it
> > will read the value of the last key in the file.
> >>>
> >>> This has actually led to the disappearance of the keyboard
> alts (the code
> > calls them mnemonics) for the main menus on the main SC screen
> for 'File'
> > and 'Help'. This is because the first listing correctly has
> file=&File but
> > the whiteboard keys replace that with file=File. (Note the
loss
> of the &).
> > There are other conflicts as well, I haven't made a complete
> list yet.
> >>>
> >>> Key names shouldn't be re-used like that, perhaps all the
> whiteboard keys
> > should be renamed with a 'whiteboard-' prefix? Either that or
> they should
> > just use the same i18n keys that are alraedy defined. (I
haven't
> used the
> > white board so I don't know what's going on here).
> >>>
> >>> We have the same potential to have other conflicts elsewhere
> (and some
> > may even exist) unless there is a naming convention of some
sort
> for i18n
> > keys. My suggestion is that anything that isn't global or
> universal should
> > have some sort of prefix related to its plugin/service/etc.
> >>>
> >>> Alan
> >>>
> >>> -------------------------------------------------------------
--
> ------
> >>> To unsubscribe, e-mail: dev-unsubscribe@sip-
> communicator.dev.java.net>>> For additional commands, e-mail:
> >>> dev-help@sip-communicator.dev.java.net
> >>>
> >>>
> >>
> >
> > ---------------------------------------------------------------
--
> ----
> > To unsubscribe, e-mail: dev-unsubscribe@sip-
> communicator.dev.java.net> For additional commands, e-mail: dev-
> help@sip-communicator.dev.java.net
> >
> >
> > ---------------------------------------------------------------
--
> ----
> > To unsubscribe, e-mail: dev-unsubscribe@sip-
> communicator.dev.java.net> For additional commands, e-mail: dev-
> help@sip-communicator.dev.java.net
> >
> >
>
> -----------------------------------------------------------------
--
> --
> To unsubscribe, e-mail: dev-unsubscribe@sip-
communicator.dev.java.net> For additional commands, e-mail: dev-
help@sip-
> communicator.dev.java.net
>

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


#10

Hey Alan,

I have some free time tomorrow so I was thinking of having a go at this
issue. I'll commit your resources file and then replace all the property
strings. I think I see how we can do this relatively easily so I hope it
would not take more than a couple of hours.

Thanks and will keep you posted.

Cheers
Emil

Alan C Kelly написа:

···

Update on the changes to resources.properties:

Attached is the newly organized properties file, with the bundle prefixes added. I am sending this out as a preview of the changes Emil and I agreed upon. Any comments are welcome.

I still have to complete the lengthy chore of adding the prefixes every place getI18NString() is called in the code. When this is finished I will submit a patch.

Unfortunately these changes mean that the various translation files will have to be redone as well.

Alan

----- Original Message -----
From: Alan C Kelly <akelly7@gmu.edu>
Date: Friday, August 8, 2008 12:19 pm
Subject: Re: [sip-comm-dev] Potentially major flaw in i18n resources.properties

Sounds good to me, I'll start working on it.

----- Original Message -----
From: Emil Ivov <emcho@sip-communicator.org>
Date: Wednesday, July 30, 2008 5:09 am
Subject: Re: [sip-comm-dev] Potentially major flaw in i18n
resources.properties

Hey Alan,

On Wed, Jul 30, 2008 at 5:11 AM, Alan Kelly <akelly7@gmu.edu> wrote:

Emil,

That sounds like a nice solution. That's going to be a lot of

changes to

make. I'm actually going to be going out of town in a couple

of

days so I'm

not likely to be able to tackle this before I leave. If it's

still an issue

when I get back late next week, I'll try working with it.

If you'd like to do it then we'll make sure it stays open for you.

Also, there are some values that would probably be global to

all

of SC, what

would we call those? Just leave off the prefix? For example,

how

> listings will we really need for the word "Help"? It seems

a

> redundant.

Good point. Guess we could follow the development convention

here and

place "public" keys in "service.gui". The idea is that everything
that's prefixed by service may be accessed in an inter-bundle and
should remain stable.

What do you think?

Emil

Alan

-----Original Message-----
From: Emil Ivov [mailto:emcho@sip-communicator.org]
Sent: Tuesday, July 29, 2008 9:00 PM
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Potentially major flaw in i18n
resources.properties

Oops, hit "Send" too quickly. What I wanted to add was that we

could agree

on using naming conventions similar to that in the

configuration

> which would give us something like:

net.java.sip.communicator.[service|impl|plugin].bundlename.RESOURCE_NAME>> > In this case we can actually even skip the

"net.java.sip.communicator"> prefix and only keep the part that
would change from one package to the

next. This way the whiteboard strings for example would have

the

> form:

plugin.whiteboard.FILE=&File (The upper case would be nice to

have but it's

not essential)

How does this sound?

Cheers
Emil

On Wed, Jul 30, 2008 at 2:52 AM, Emil Ivov <emcho@sip- >>> communicator.org>> wrote:

Hey Alan,

Yes, that's a good point. I even remember actually discussing the
unification of resource strings with someone but I guess no

one

>> around to it.

Interested in proposing a patch?

Emil

On Tue, Jul 29, 2008 at 8:21 PM, Alan C Kelly

<akelly7@gmu.edu>

wrote:>>> Hi, me again...

I stumbled into a bug in the i18n properties files in

resources\languages. The new whiteboard section is reusing key

names that

have already been used, such as 'file' and 'about' This causes

a

> problem when
net.java.sip.communicator.impl.gui.i18n.Messages reads the

translation values. If there is more than one key with the

same

name, it

will read the value of the last key in the file.

This has actually led to the disappearance of the keyboard

alts (the code

calls them mnemonics) for the main menus on the main SC screen

for 'File'

and 'Help'. This is because the first listing correctly has

file=&File but

the whiteboard keys replace that with file=File. (Note the

loss

of the &).

There are other conflicts as well, I haven't made a complete

list yet.

Key names shouldn't be re-used like that, perhaps all the

whiteboard keys

should be renamed with a 'whiteboard-' prefix? Either that or

they should

just use the same i18n keys that are alraedy defined. (I

haven't

used the

white board so I don't know what's going on here).

We have the same potential to have other conflicts elsewhere

(and some

may even exist) unless there is a naming convention of some

sort

for i18n

keys. My suggestion is that anything that isn't global or

universal should

have some sort of prefix related to its plugin/service/etc.

Alan

-------------------------------------------------------------

--

------

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net>>> For additional commands, e-mail:

dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------

--

----

To unsubscribe, e-mail: dev-unsubscribe@sip-

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

---------------------------------------------------------------

--

----

To unsubscribe, e-mail: dev-unsubscribe@sip-

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

-----------------------------------------------------------------

--

--
To unsubscribe, e-mail: dev-unsubscribe@sip-

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

communicator.dev.java.net

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

------------------------------------------------------------------------

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

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


#11

Hi Emil,

I've already replaced them for a number of the files, you you like me to send you a patch file for the ones I've already done?

Let me know. I've done a search and located all the usages of getI18NString(), but changing them all one by one is tedious so if you have a better idea, that would be great.

Alan

···

----- Original Message -----

From: Emil Ivov <emcho@sip-communicator.org>

Date: Thursday, August 14, 2008 9:22 am
Subject: Re: [sip-comm-dev] Update on changes to resources.properties

Hey Alan,

I have some free time tomorrow so I was thinking of having a go at
thisissue. I'll commit your resources file and then replace all
the property
strings. I think I see how we can do this relatively easily so I
hope it
would not take more than a couple of hours.

Thanks and will keep you posted.

Cheers
Emil

Alan C Kelly написа:
> Update on the changes to resources.properties:
>
> Attached is the newly organized properties file, with the bundle
prefixes added. I am sending this out as a preview of the changes
Emil and I agreed upon. Any comments are welcome.
>
> I still have to complete the lengthy chore of adding the
prefixes every place getI18NString() is called in the code. When
this is finished I will submit a patch.
>
> Unfortunately these changes mean that the various translation
files will have to be redone as well.
>
> Alan
>
> ----- Original Message -----
> From: Alan C Kelly <akelly7@gmu.edu>
> Date: Friday, August 8, 2008 12:19 pm
> Subject: Re: [sip-comm-dev] Potentially major flaw in i18n
resources.properties>
>> Sounds good to me, I'll start working on it.
>>
>> ----- Original Message -----
>> From: Emil Ivov <emcho@sip-communicator.org>
>> Date: Wednesday, July 30, 2008 5:09 am
>> Subject: Re: [sip-comm-dev] Potentially major flaw in i18n
>> resources.properties
>>> Hey Alan,
>>>
>>> On Wed, Jul 30, 2008 at 5:11 AM, Alan Kelly <akelly7@gmu.edu>
wrote:>>>> Emil,
>>>>
>>>> That sounds like a nice solution. That's going to be a lot of
>>> changes to
>>>> make. I'm actually going to be going out of town in a couple
>> of
>>> days so I'm
>>>> not likely to be able to tackle this before I leave. If it's
>>> still an issue
>>>> when I get back late next week, I'll try working with it.
>>> If you'd like to do it then we'll make sure it stays open for you.
>>>
>>>> Also, there are some values that would probably be global to
>> all
>>> of SC, what
>>>> would we call those? Just leave off the prefix? For example,
>> how
>>> > listings will we really need for the word "Help"? It
seems
>> a
>>> > redundant.
>>>
>>> Good point. Guess we could follow the development convention
>> here and
>>> place "public" keys in "service.gui". The idea is that everything
>>> that's prefixed by service may be accessed in an inter-bundle and
>>> should remain stable.
>>>
>>> What do you think?
>>>
>>> Emil
>>>> Alan
>>>>
>>>> -----Original Message-----
>>>> From: Emil Ivov [mailto:emcho@sip-communicator.org]
>>>> Sent: Tuesday, July 29, 2008 9:00 PM
>>>> To: dev@sip-communicator.dev.java.net
>>>> Subject: Re: [sip-comm-dev] Potentially major flaw in i18n
>>>> resources.properties
>>>>
>>>> Oops, hit "Send" too quickly. What I wanted to add was that
we
>>> could agree
>>>> on using naming conventions similar to that in the
>> configuration
>>> > which would give us something like:
>>>>
>>
net.java.sip.communicator.[service|impl|plugin].bundlename.RESOURCE_NAME>> > In this case we can actually even skip the
>>> "net.java.sip.communicator"> prefix and only keep the part
that
>>> would change from one package to the
>>>> next. This way the whiteboard strings for example would have
>> the
>>> > form:
>>>> plugin.whiteboard.FILE=&File (The upper case would be nice to
>>> have but it's
>>>> not essential)
>>>>
>>>> How does this sound?
>>>>
>>>> Cheers
>>>> Emil
>>>>
>>>> On Wed, Jul 30, 2008 at 2:52 AM, Emil Ivov <emcho@sip- > >>> communicator.org>> wrote:
>>>>> Hey Alan,
>>>>>
>>>>> Yes, that's a good point. I even remember actually
discussing the
>>>>> unification of resource strings with someone but I guess no
>> one
>>> >> around to it.
>>>>> Interested in proposing a patch?
>>>>>
>>>>> Emil
>>>>>
>>>>> On Tue, Jul 29, 2008 at 8:21 PM, Alan C Kelly
>> <akelly7@gmu.edu>
>>> wrote:>>> Hi, me again...
>>>>>> I stumbled into a bug in the i18n properties files in
>>>> resources\languages. The new whiteboard section is reusing
key
>>> names that
>>>> have already been used, such as 'file' and 'about' This
causes
>> a
>>> > problem when
>>> net.java.sip.communicator.impl.gui.i18n.Messages reads the
>>>> translation values. If there is more than one key with the
>> same
>>> name, it
>>>> will read the value of the last key in the file.
>>>>>> This has actually led to the disappearance of the keyboard
>>> alts (the code
>>>> calls them mnemonics) for the main menus on the main SC
screen
>>> for 'File'
>>>> and 'Help'. This is because the first listing correctly has
>>> file=&File but
>>>> the whiteboard keys replace that with file=File. (Note the
>> loss
>>> of the &).
>>>> There are other conflicts as well, I haven't made a complete
>>> list yet.
>>>>>> Key names shouldn't be re-used like that, perhaps all the
>>> whiteboard keys
>>>> should be renamed with a 'whiteboard-' prefix? Either that or
>>> they should
>>>> just use the same i18n keys that are alraedy defined. (I
>> haven't
>>> used the
>>>> white board so I don't know what's going on here).
>>>>>> We have the same potential to have other conflicts
elsewhere
>>> (and some
>>>> may even exist) unless there is a naming convention of some
>> sort
>>> for i18n
>>>> keys. My suggestion is that anything that isn't global or
>>> universal should
>>>> have some sort of prefix related to its plugin/service/etc.
>>>>>> Alan
>>>>>>
>>>>>> ------------------------------------------------------------
-
>> --
>>> ------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@sip-
>>> communicator.dev.java.net>>> For additional commands, e-mail:
>>>>>> dev-help@sip-communicator.dev.java.net
>>>>>>
>>>>>>
>>>> --------------------------------------------------------------
-
>> --
>>> ----
>>>> To unsubscribe, e-mail: dev-unsubscribe@sip-
>>> communicator.dev.java.net> For additional commands, e-mail:
dev-
>>> help@sip-communicator.dev.java.net
>>>>
>>>> --------------------------------------------------------------
-
>> --
>>> ----
>>>> To unsubscribe, e-mail: dev-unsubscribe@sip-
>>> communicator.dev.java.net> For additional commands, e-mail:
dev-
>>> help@sip-communicator.dev.java.net
>>>>
>>> ---------------------------------------------------------------
--
>> --
>>> --
>>> To unsubscribe, e-mail: dev-unsubscribe@sip-
>> communicator.dev.java.net> For additional commands, e-mail: dev-
>> help@sip-
>>> communicator.dev.java.net
>>>
>> ----------------------------------------------------------------
---
>> --
>> To unsubscribe, e-mail: dev-unsubscribe@sip-
communicator.dev.java.net>> For additional commands, e-mail: dev-
help@sip-
>> communicator.dev.java.net
>>
>>
>> ----------------------------------------------------------------
--------
>>
>> ----------------------------------------------------------------
-----
>> To unsubscribe, e-mail: dev-unsubscribe@sip-
communicator.dev.java.net>> For additional commands, e-mail: dev-
help@sip-communicator.dev.java.net

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

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


#12

Hey Alan,

Yes please, I'd like to have the patch. Thanks for suggesting!. I'll
apply it and take it from there.

Cheers
Emil

Alan C Kelly написа:

···

Hi Emil,

I've already replaced them for a number of the files, you you like me to send you a patch file for the ones I've already done?

Let me know. I've done a search and located all the usages of getI18NString(), but changing them all one by one is tedious so if you have a better idea, that would be great.

Alan

----- Original Message -----
From: Emil Ivov <emcho@sip-communicator.org>
Date: Thursday, August 14, 2008 9:22 am
Subject: Re: [sip-comm-dev] Update on changes to resources.properties

Hey Alan,

I have some free time tomorrow so I was thinking of having a go at
thisissue. I'll commit your resources file and then replace all
the property
strings. I think I see how we can do this relatively easily so I
hope it
would not take more than a couple of hours.

Thanks and will keep you posted.

Cheers
Emil

Alan C Kelly написа:

Update on the changes to resources.properties:

Attached is the newly organized properties file, with the bundle

prefixes added. I am sending this out as a preview of the changes
Emil and I agreed upon. Any comments are welcome.

I still have to complete the lengthy chore of adding the

prefixes every place getI18NString() is called in the code. When
this is finished I will submit a patch.

Unfortunately these changes mean that the various translation

files will have to be redone as well.

Alan

----- Original Message -----
From: Alan C Kelly <akelly7@gmu.edu>
Date: Friday, August 8, 2008 12:19 pm
Subject: Re: [sip-comm-dev] Potentially major flaw in i18n

resources.properties>

Sounds good to me, I'll start working on it.

----- Original Message -----
From: Emil Ivov <emcho@sip-communicator.org>
Date: Wednesday, July 30, 2008 5:09 am
Subject: Re: [sip-comm-dev] Potentially major flaw in i18n
resources.properties

Hey Alan,

On Wed, Jul 30, 2008 at 5:11 AM, Alan Kelly <akelly7@gmu.edu>

wrote:>>>> Emil,

That sounds like a nice solution. That's going to be a lot of

changes to

make. I'm actually going to be going out of town in a couple

of

days so I'm

not likely to be able to tackle this before I leave. If it's

still an issue

when I get back late next week, I'll try working with it.

If you'd like to do it then we'll make sure it stays open for you.

Also, there are some values that would probably be global to

all

of SC, what

would we call those? Just leave off the prefix? For example,

how

> listings will we really need for the word "Help"? It

seems

a

> redundant.

Good point. Guess we could follow the development convention

here and

place "public" keys in "service.gui". The idea is that everything
that's prefixed by service may be accessed in an inter-bundle and
should remain stable.

What do you think?

Emil

Alan

-----Original Message-----
From: Emil Ivov [mailto:emcho@sip-communicator.org]
Sent: Tuesday, July 29, 2008 9:00 PM
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Potentially major flaw in i18n
resources.properties

Oops, hit "Send" too quickly. What I wanted to add was that

we

could agree

on using naming conventions similar to that in the

configuration

> which would give us something like:

net.java.sip.communicator.[service|impl|plugin].bundlename.RESOURCE_NAME>> > In this case we can actually even skip the

"net.java.sip.communicator"> prefix and only keep the part

that

would change from one package to the

next. This way the whiteboard strings for example would have

the

> form:

plugin.whiteboard.FILE=&File (The upper case would be nice to

have but it's

not essential)

How does this sound?

Cheers
Emil

On Wed, Jul 30, 2008 at 2:52 AM, Emil Ivov <emcho@sip- >>>>> communicator.org>> wrote:

Hey Alan,

Yes, that's a good point. I even remember actually

discussing the

unification of resource strings with someone but I guess no

one

>> around to it.

Interested in proposing a patch?

Emil

On Tue, Jul 29, 2008 at 8:21 PM, Alan C Kelly

<akelly7@gmu.edu>

wrote:>>> Hi, me again...

I stumbled into a bug in the i18n properties files in

resources\languages. The new whiteboard section is reusing

key

names that

have already been used, such as 'file' and 'about' This

causes

a

> problem when
net.java.sip.communicator.impl.gui.i18n.Messages reads the

translation values. If there is more than one key with the

same

name, it

will read the value of the last key in the file.

This has actually led to the disappearance of the keyboard

alts (the code

calls them mnemonics) for the main menus on the main SC

screen

for 'File'

and 'Help'. This is because the first listing correctly has

file=&File but

the whiteboard keys replace that with file=File. (Note the

loss

of the &).

There are other conflicts as well, I haven't made a complete

list yet.

Key names shouldn't be re-used like that, perhaps all the

whiteboard keys

should be renamed with a 'whiteboard-' prefix? Either that or

they should

just use the same i18n keys that are alraedy defined. (I

haven't

used the

white board so I don't know what's going on here).

We have the same potential to have other conflicts

elsewhere

(and some

may even exist) unless there is a naming convention of some

sort

for i18n

keys. My suggestion is that anything that isn't global or

universal should

have some sort of prefix related to its plugin/service/etc.

Alan

------------------------------------------------------------

-

--

------

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net>>> For additional commands, e-mail:

dev-help@sip-communicator.dev.java.net

--------------------------------------------------------------

-

--

----

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net> For additional commands, e-mail:

dev-

help@sip-communicator.dev.java.net

--------------------------------------------------------------

-

--

----

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net> For additional commands, e-mail:

dev-

help@sip-communicator.dev.java.net
---------------------------------------------------------------

--

--

--
To unsubscribe, e-mail: dev-unsubscribe@sip-

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

communicator.dev.java.net

----------------------------------------------------------------

---

--
To unsubscribe, e-mail: dev-unsubscribe@sip-

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

communicator.dev.java.net

----------------------------------------------------------------

--------

----------------------------------------------------------------

-----

To unsubscribe, e-mail: dev-unsubscribe@sip-

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

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

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

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


#13

Hi Emil,

Here is the patch file.

I was just thinking, should we be making the same prefix changes to images.properties and the other x.properties resource files?

Alan

i18n_update_started.patch (34.9 KB)

···

----- Original Message -----

From: Emil Ivov <emcho@sip-communicator.org>

Date: Thursday, August 14, 2008 9:35 am
Subject: Re: [sip-comm-dev] Update on changes to resources.properties

Hey Alan,

Yes please, I'd like to have the patch. Thanks for suggesting!. I'll
apply it and take it from there.

Cheers
Emil

Alan C Kelly написа:
> Hi Emil,
>
> I've already replaced them for a number of the files, you you
like me to send you a patch file for the ones I've already done?
>
> Let me know. I've done a search and located all the usages of
getI18NString(), but changing them all one by one is tedious so if
you have a better idea, that would be great.
>
> Alan
>
> ----- Original Message -----
> From: Emil Ivov <emcho@sip-communicator.org>
> Date: Thursday, August 14, 2008 9:22 am
> Subject: Re: [sip-comm-dev] Update on changes to
resources.properties>
>> Hey Alan,
>>
>> I have some free time tomorrow so I was thinking of having a go
at
>> thisissue. I'll commit your resources file and then replace all
>> the property
>> strings. I think I see how we can do this relatively easily so
I
>> hope it
>> would not take more than a couple of hours.
>>
>> Thanks and will keep you posted.
>>
>> Cheers
>> Emil
>>
>>
>>
>> Alan C Kelly написа:
>>> Update on the changes to resources.properties:
>>>
>>> Attached is the newly organized properties file, with the
bundle
>> prefixes added. I am sending this out as a preview of the
changes
>> Emil and I agreed upon. Any comments are welcome.
>>> I still have to complete the lengthy chore of adding the
>> prefixes every place getI18NString() is called in the code.
When
>> this is finished I will submit a patch.
>>> Unfortunately these changes mean that the various translation
>> files will have to be redone as well.
>>> Alan
>>>
>>> ----- Original Message -----
>>> From: Alan C Kelly <akelly7@gmu.edu>
>>> Date: Friday, August 8, 2008 12:19 pm
>>> Subject: Re: [sip-comm-dev] Potentially major flaw in i18n
>> resources.properties>
>>>> Sounds good to me, I'll start working on it.
>>>>
>>>> ----- Original Message -----
>>>> From: Emil Ivov <emcho@sip-communicator.org>
>>>> Date: Wednesday, July 30, 2008 5:09 am
>>>> Subject: Re: [sip-comm-dev] Potentially major flaw in i18n
>>>> resources.properties
>>>>> Hey Alan,
>>>>>
>>>>> On Wed, Jul 30, 2008 at 5:11 AM, Alan Kelly
<akelly7@gmu.edu>
>> wrote:>>>> Emil,
>>>>>> That sounds like a nice solution. That's going to be a lot
of
>>>>> changes to
>>>>>> make. I'm actually going to be going out of town in a
couple
>>>> of
>>>>> days so I'm
>>>>>> not likely to be able to tackle this before I leave. If
it's
>>>>> still an issue
>>>>>> when I get back late next week, I'll try working with it.
>>>>> If you'd like to do it then we'll make sure it stays open
for you.
>>>>>
>>>>>> Also, there are some values that would probably be global
to
>>>> all
>>>>> of SC, what
>>>>>> would we call those? Just leave off the prefix? For
example,
>>>> how
>>>>> > listings will we really need for the word "Help"? It
>> seems
>>>> a
>>>>> > redundant.
>>>>>
>>>>> Good point. Guess we could follow the development convention
>>>> here and
>>>>> place "public" keys in "service.gui". The idea is that
>>>>> that's prefixed by service may be accessed in an
inter-bundle and
>>>>> should remain stable.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Emil
>>>>>> Alan
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Emil Ivov [mailto:emcho@sip-communicator.org]
>>>>>> Sent: Tuesday, July 29, 2008 9:00 PM
>>>>>> To: dev@sip-communicator.dev.java.net
>>>>>> Subject: Re: [sip-comm-dev] Potentially major flaw in i18n
>>>>>> resources.properties
>>>>>>
>>>>>> Oops, hit "Send" too quickly. What I wanted to add was that
>> we
>>>>> could agree
>>>>>> on using naming conventions similar to that in the
>>>> configuration
>>>>> > which would give us something like:
>>
net.java.sip.communicator.[service|impl|plugin].bundlename.RESOURCE_NAME>> > In this case we can actually even skip the
>>>>> "net.java.sip.communicator"> prefix and only keep the part
>> that
>>>>> would change from one package to the
>>>>>> next. This way the whiteboard strings for example would
have
>>>> the
>>>>> > form:
>>>>>> plugin.whiteboard.FILE=&File (The upper case would be nice
to
>>>>> have but it's
>>>>>> not essential)
>>>>>>
>>>>>> How does this sound?
>>>>>>
>>>>>> Cheers
>>>>>> Emil
>>>>>>
>>>>>> On Wed, Jul 30, 2008 at 2:52 AM, Emil Ivov <emcho@sip- > >>>>> communicator.org>> wrote:
>>>>>>> Hey Alan,
>>>>>>>
>>>>>>> Yes, that's a good point. I even remember actually
>> discussing the
>>>>>>> unification of resource strings with someone but I guess
no
>>>> one
>>>>> >> around to it.
>>>>>>> Interested in proposing a patch?
>>>>>>>
>>>>>>> Emil
>>>>>>>
>>>>>>> On Tue, Jul 29, 2008 at 8:21 PM, Alan C Kelly
>>>> <akelly7@gmu.edu>
>>>>> wrote:>>> Hi, me again...
>>>>>>>> I stumbled into a bug in the i18n properties files in
>>>>>> resources\languages. The new whiteboard section is reusing
>> key
>>>>> names that
>>>>>> have already been used, such as 'file' and 'about' This
>> causes
>>>> a
>>>>> > problem when
>>>>> net.java.sip.communicator.impl.gui.i18n.Messages reads the
>>>>>> translation values. If there is more than one key with the
>>>> same
>>>>> name, it
>>>>>> will read the value of the last key in the file.
>>>>>>>> This has actually led to the disappearance of the
keyboard
>>>>> alts (the code
>>>>>> calls them mnemonics) for the main menus on the main SC
>> screen
>>>>> for 'File'
>>>>>> and 'Help'. This is because the first listing correctly has
>>>>> file=&File but
>>>>>> the whiteboard keys replace that with file=File. (Note the
>>>> loss
>>>>> of the &).
>>>>>> There are other conflicts as well, I haven't made a
complete
>>>>> list yet.
>>>>>>>> Key names shouldn't be re-used like that, perhaps all the
>>>>> whiteboard keys
>>>>>> should be renamed with a 'whiteboard-' prefix? Either that
or
>>>>> they should
>>>>>> just use the same i18n keys that are alraedy defined. (I
>>>> haven't
>>>>> used the
>>>>>> white board so I don't know what's going on here).
>>>>>>>> We have the same potential to have other conflicts
>> elsewhere
>>>>> (and some
>>>>>> may even exist) unless there is a naming convention of some
>>>> sort
>>>>> for i18n
>>>>>> keys. My suggestion is that anything that isn't global or
>>>>> universal should
>>>>>> have some sort of prefix related to its plugin/service/etc.
>>>>>>>> Alan
>>>>>>>>
>>>>>>>> ----------------------------------------------------------
--
>> -
>>>> --
>>>>> ------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@sip-
>>>>> communicator.dev.java.net>>> For additional commands, e-mail:
>>>>>>>> dev-help@sip-communicator.dev.java.net
>>>>>>>>
>>>>>>>>
>>>>>> ------------------------------------------------------------
--
>> -
>>>> --
>>>>> ----
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@sip-
>>>>> communicator.dev.java.net> For additional commands, e-mail:
>> dev-
>>>>> help@sip-communicator.dev.java.net
>>>>>> ------------------------------------------------------------
--
>> -
>>>> --
>>>>> ----
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@sip-
>>>>> communicator.dev.java.net> For additional commands, e-mail:
>> dev-
>>>>> help@sip-communicator.dev.java.net
>>>>> -------------------------------------------------------------
--
>> --
>>>> --
>>>>> --
>>>>> To unsubscribe, e-mail: dev-unsubscribe@sip-
>>>> communicator.dev.java.net> For additional commands, e-mail:
dev-
>>>> help@sip-
>>>>> communicator.dev.java.net
>>>>>
>>>> --------------------------------------------------------------
--
>> ---
>>>> --
>>>> To unsubscribe, e-mail: dev-unsubscribe@sip-
>> communicator.dev.java.net>> For additional commands, e-mail:
dev-
>> help@sip-
>>>> communicator.dev.java.net
>>>>
>>>>
>>>> --------------------------------------------------------------
--
>> --------
>>>> --------------------------------------------------------------
--
>> -----
>>>> To unsubscribe, e-mail: dev-unsubscribe@sip-
>> communicator.dev.java.net>> For additional commands, e-mail:
dev-
>> help@sip-communicator.dev.java.net
>>
>>
>> ----------------------------------------------------------------
---
>> --
>> To unsubscribe, e-mail: dev-unsubscribe@sip-
communicator.dev.java.net>> For additional commands, e-mail: dev-
help@sip-
>> communicator.dev.java.net
>>
>
> -----------------------------------------------------------------
----
> To unsubscribe, e-mail: dev-unsubscribe@sip-
communicator.dev.java.net> For additional commands, e-mail: dev-
help@sip-communicator.dev.java.net
>
>

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


#14

Hey Alan,

Alan C Kelly написа:

Hi Emil,

Here is the patch file.

Thanks!

I was just thinking, should we be making the same prefix changes to
images.properties and the other x.properties resource files?

Yes, absolutely! We've actually had a bug in one of the
images.properties files quite recently so I was also planning on
changing these.

Cheers
Emil

···

Alan

----- Original Message ----- From: Emil Ivov
<emcho@sip-communicator.org> Date: Thursday, August 14, 2008 9:35 am
Subject: Re: [sip-comm-dev] Update on changes to resources.properties

Hey Alan,

Yes please, I'd like to have the patch. Thanks for suggesting!.
I'll apply it and take it from there.

Cheers Emil

Alan C Kelly написа:

Hi Emil,

I've already replaced them for a number of the files, you you

like me to send you a patch file for the ones I've already done?

Let me know. I've done a search and located all the usages of

getI18NString(), but changing them all one by one is tedious so if
you have a better idea, that would be great.

Alan

----- Original Message ----- From: Emil Ivov
<emcho@sip-communicator.org> Date: Thursday, August 14, 2008 9:22
am Subject: Re: [sip-comm-dev] Update on changes to

resources.properties>

Hey Alan,

I have some free time tomorrow so I was thinking of having a go

at

thisissue. I'll commit your resources file and then replace all
the property strings. I think I see how we can do this
relatively easily so

I

hope it would not take more than a couple of hours.

Thanks and will keep you posted.

Cheers Emil

Alan C Kelly написа:

Update on the changes to resources.properties:

Attached is the newly organized properties file, with the

bundle

prefixes added. I am sending this out as a preview of the

changes

Emil and I agreed upon. Any comments are welcome.

I still have to complete the lengthy chore of adding the

prefixes every place getI18NString() is called in the code.

When

this is finished I will submit a patch.

Unfortunately these changes mean that the various translation

files will have to be redone as well.

Alan

----- Original Message ----- From: Alan C Kelly
<akelly7@gmu.edu> Date: Friday, August 8, 2008 12:19 pm
Subject: Re: [sip-comm-dev] Potentially major flaw in i18n

resources.properties>

Sounds good to me, I'll start working on it.

----- Original Message ----- From: Emil Ivov
<emcho@sip-communicator.org> Date: Wednesday, July 30, 2008
5:09 am Subject: Re: [sip-comm-dev] Potentially major flaw
in i18n resources.properties

Hey Alan,

On Wed, Jul 30, 2008 at 5:11 AM, Alan Kelly

<akelly7@gmu.edu>

wrote:>>>> Emil,

That sounds like a nice solution. That's going to be a
lot

of

changes to

make. I'm actually going to be going out of town in a

couple

of

days so I'm

not likely to be able to tackle this before I leave. If

it's

still an issue

when I get back late next week, I'll try working with
it.

If you'd like to do it then we'll make sure it stays open

for you.

Also, there are some values that would probably be
global

to

all

of SC, what

would we call those? Just leave off the prefix? For

example,

how

> listings will we really need for the word "Help"?
It

seems

a

> redundant.

Good point. Guess we could follow the development
convention

here and

place "public" keys in "service.gui". The idea is that

>>>>> that's prefixed by service may be accessed in an
inter-bundle and

should remain stable.

What do you think?

Emil

Alan

-----Original Message----- From: Emil Ivov
[mailto:emcho@sip-communicator.org] Sent: Tuesday, July
29, 2008 9:00 PM To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Potentially major flaw in
i18n resources.properties

Oops, hit "Send" too quickly. What I wanted to add was
that

we

could agree

on using naming conventions similar to that in the

configuration

> which would give us something like:

net.java.sip.communicator.[service|impl|plugin].bundlename.RESOURCE_NAME>>
> In this case we can actually even skip the

"net.java.sip.communicator"> prefix and only keep the
part

that

would change from one package to the

next. This way the whiteboard strings for example would

have

the

> form:

plugin.whiteboard.FILE=&File (The upper case would be
nice

to

have but it's

not essential)

How does this sound?

Cheers Emil

On Wed, Jul 30, 2008 at 2:52 AM, Emil Ivov <emcho@sip- >>>>>>> communicator.org>> wrote:

Hey Alan,

Yes, that's a good point. I even remember actually

discussing the

unification of resource strings with someone but I
guess

no

one

>> around to it.

Interested in proposing a patch?

Emil

On Tue, Jul 29, 2008 at 8:21 PM, Alan C Kelly

<akelly7@gmu.edu>

wrote:>>> Hi, me again...

I stumbled into a bug in the i18n properties files
in

resources\languages. The new whiteboard section is
reusing

key

names that

have already been used, such as 'file' and 'about' This

causes

a

> problem when
net.java.sip.communicator.impl.gui.i18n.Messages reads
the

translation values. If there is more than one key with
the

same

name, it

will read the value of the last key in the file.

This has actually led to the disappearance of the

keyboard

alts (the code

calls them mnemonics) for the main menus on the main SC

screen

for 'File'

and 'Help'. This is because the first listing correctly
has

file=&File but

the whiteboard keys replace that with file=File. (Note
the

loss

of the &).

There are other conflicts as well, I haven't made a

complete

list yet.

Key names shouldn't be re-used like that, perhaps
all the

whiteboard keys

should be renamed with a 'whiteboard-' prefix? Either
that

or

they should

just use the same i18n keys that are alraedy defined.
(I

haven't

used the

white board so I don't know what's going on here).

We have the same potential to have other conflicts

elsewhere

(and some

may even exist) unless there is a naming convention of
some

sort

for i18n

keys. My suggestion is that anything that isn't global
or

universal should

have some sort of prefix related to its
plugin/service/etc.

Alan

----------------------------------------------------------

--

-

--

------

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net>>> For additional commands,
e-mail:

dev-help@sip-communicator.dev.java.net

------------------------------------------------------------

--

-

--

----

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net> For additional commands,
e-mail:

dev-

help@sip-communicator.dev.java.net

------------------------------------------------------------

--

-

--

----

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net> For additional commands,
e-mail:

dev-

help@sip-communicator.dev.java.net
-------------------------------------------------------------

--

--

--

-- To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net> For additional commands, e-mail:

dev-

help@sip-

communicator.dev.java.net

--------------------------------------------------------------

--

---

-- To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net>> For additional commands, e-mail:

dev-

help@sip-

communicator.dev.java.net

--------------------------------------------------------------

--

--------

--------------------------------------------------------------

--

-----

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net>> For additional commands, e-mail:

dev-

help@sip-communicator.dev.java.net

----------------------------------------------------------------

---

-- To unsubscribe, e-mail: dev-unsubscribe@sip-

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

communicator.dev.java.net

-----------------------------------------------------------------

----

To unsubscribe, e-mail: dev-unsubscribe@sip-

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

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

------------------------------------------------------------------------

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

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


#15

Hi Emil,

Attached are some more updated properties files.

Alan

colors.properties (3.96 KB)

images.properties (29.2 KB)

sounds.properties (838 Bytes)

defaults.properties (1.42 KB)

···

----- Original Message -----

From: Emil Ivov <emcho@sip-communicator.org>

Date: Thursday, August 14, 2008 10:47 am
Subject: Re: [sip-comm-dev] Update on changes to resources.properties

Hey Alan,

Alan C Kelly написа:
> Hi Emil,
>
> Here is the patch file.

Thanks!

> I was just thinking, should we be making the same prefix changes to
> images.properties and the other x.properties resource files?

Yes, absolutely! We've actually had a bug in one of the
images.properties files quite recently so I was also planning on
changing these.

Cheers
Emil
>
> Alan
>
> ----- Original Message ----- From: Emil Ivov
> <emcho@sip-communicator.org> Date: Thursday, August 14, 2008
9:35 am
> Subject: Re: [sip-comm-dev] Update on changes to
resources.properties>
>
>> Hey Alan,
>>
>> Yes please, I'd like to have the patch. Thanks for suggesting!.
>> I'll apply it and take it from there.
>>
>> Cheers Emil
>>
>> Alan C Kelly написа:
>>> Hi Emil,
>>>
>>> I've already replaced them for a number of the files, you you
>> like me to send you a patch file for the ones I've already done?
>>> Let me know. I've done a search and located all the usages of
>> getI18NString(), but changing them all one by one is tedious so if
>> you have a better idea, that would be great.
>>> Alan
>>>
>>> ----- Original Message ----- From: Emil Ivov
>>> <emcho@sip-communicator.org> Date: Thursday, August 14, 2008 9:22
>>> am Subject: Re: [sip-comm-dev] Update on changes to
>> resources.properties>
>>>> Hey Alan,
>>>>
>>>> I have some free time tomorrow so I was thinking of having a go
>>>>
>> at
>>>> thisissue. I'll commit your resources file and then replace all
>>>> the property strings. I think I see how we can do this
>>>> relatively easily so
>> I
>>>> hope it would not take more than a couple of hours.
>>>>
>>>> Thanks and will keep you posted.
>>>>
>>>> Cheers Emil
>>>>
>>>>
>>>>
>>>> Alan C Kelly написа:
>>>>> Update on the changes to resources.properties:
>>>>>
>>>>> Attached is the newly organized properties file, with the
>> bundle
>>>> prefixes added. I am sending this out as a preview of the
>> changes
>>>> Emil and I agreed upon. Any comments are welcome.
>>>>> I still have to complete the lengthy chore of adding the
>>>> prefixes every place getI18NString() is called in the code.
>> When
>>>> this is finished I will submit a patch.
>>>>> Unfortunately these changes mean that the various translation
>>>>>
>>>> files will have to be redone as well.
>>>>> Alan
>>>>>
>>>>> ----- Original Message ----- From: Alan C Kelly
>>>>> <akelly7@gmu.edu> Date: Friday, August 8, 2008 12:19 pm
>>>>> Subject: Re: [sip-comm-dev] Potentially major flaw in i18n
>>>> resources.properties>
>>>>>> Sounds good to me, I'll start working on it.
>>>>>>
>>>>>> ----- Original Message ----- From: Emil Ivov
>>>>>> <emcho@sip-communicator.org> Date: Wednesday, July 30, 2008
>>>>>> 5:09 am Subject: Re: [sip-comm-dev] Potentially major flaw
>>>>>> in i18n resources.properties
>>>>>>> Hey Alan,
>>>>>>>
>>>>>>> On Wed, Jul 30, 2008 at 5:11 AM, Alan Kelly
>> <akelly7@gmu.edu>
>>>> wrote:>>>> Emil,
>>>>>>>> That sounds like a nice solution. That's going to be a
>>>>>>>> lot
>> of
>>>>>>> changes to
>>>>>>>> make. I'm actually going to be going out of town in a
>> couple
>>>>>> of
>>>>>>> days so I'm
>>>>>>>> not likely to be able to tackle this before I leave. If
>>>>>>>>
>> it's
>>>>>>> still an issue
>>>>>>>> when I get back late next week, I'll try working with
>>>>>>>> it.
>>>>>>> If you'd like to do it then we'll make sure it stays open
>>>>>>>
>> for you.
>>>>>>>> Also, there are some values that would probably be
>>>>>>>> global
>> to
>>>>>> all
>>>>>>> of SC, what
>>>>>>>> would we call those? Just leave off the prefix? For
>> example,
>>>>>> how
>>>>>>> > listings will we really need for the word "Help"?
>>>>>>> It
>>>> seems
>>>>>> a
>>>>>>> > redundant.
>>>>>>>
>>>>>>> Good point. Guess we could follow the development
>>>>>>> convention
>>>>>> here and
>>>>>>> place "public" keys in "service.gui". The idea is that
>> >>>>> that's prefixed by service may be accessed in
an
>> inter-bundle and
>>>>>>> should remain stable.
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>> Emil
>>>>>>>> Alan
>>>>>>>>
>>>>>>>> -----Original Message----- From: Emil Ivov
>>>>>>>> [mailto:emcho@sip-communicator.org] Sent: Tuesday, July
>>>>>>>> 29, 2008 9:00 PM To: dev@sip-communicator.dev.java.net
>>>>>>>> Subject: Re: [sip-comm-dev] Potentially major flaw in
>>>>>>>> i18n resources.properties
>>>>>>>>
>>>>>>>> Oops, hit "Send" too quickly. What I wanted to add was
>>>>>>>> that
>>>> we
>>>>>>> could agree
>>>>>>>> on using naming conventions similar to that in the
>>>>>> configuration
>>>>>>> > which would give us something like:
>>
net.java.sip.communicator.[service|impl|plugin].bundlename.RESOURCE_NAME>>>> > In this case we can actually even skip the
>>>>>>> "net.java.sip.communicator"> prefix and only keep the
>>>>>>> part
>>>> that
>>>>>>> would change from one package to the
>>>>>>>> next. This way the whiteboard strings for example would
>>>>>>>>
>> have
>>>>>> the
>>>>>>> > form:
>>>>>>>> plugin.whiteboard.FILE=&File (The upper case would be
>>>>>>>> nice
>> to
>>>>>>> have but it's
>>>>>>>> not essential)
>>>>>>>>
>>>>>>>> How does this sound?
>>>>>>>>
>>>>>>>> Cheers Emil
>>>>>>>>
>>>>>>>> On Wed, Jul 30, 2008 at 2:52 AM, Emil Ivov <emcho@sip- > >>>>>>> communicator.org>> wrote:
>>>>>>>>> Hey Alan,
>>>>>>>>>
>>>>>>>>> Yes, that's a good point. I even remember actually
>>>> discussing the
>>>>>>>>> unification of resource strings with someone but I
>>>>>>>>> guess
>> no
>>>>>> one
>>>>>>> >> around to it.
>>>>>>>>> Interested in proposing a patch?
>>>>>>>>>
>>>>>>>>> Emil
>>>>>>>>>
>>>>>>>>> On Tue, Jul 29, 2008 at 8:21 PM, Alan C Kelly
>>>>>> <akelly7@gmu.edu>
>>>>>>> wrote:>>> Hi, me again...
>>>>>>>>>> I stumbled into a bug in the i18n properties files
>>>>>>>>>> in
>>>>>>>> resources\languages. The new whiteboard section is
>>>>>>>> reusing
>>>> key
>>>>>>> names that
>>>>>>>> have already been used, such as 'file' and 'about' This
>>>>>>>>
>>>> causes
>>>>>> a
>>>>>>> > problem when
>>>>>>> net.java.sip.communicator.impl.gui.i18n.Messages reads
>>>>>>> the
>>>>>>>> translation values. If there is more than one key with
>>>>>>>> the
>>>>>> same
>>>>>>> name, it
>>>>>>>> will read the value of the last key in the file.
>>>>>>>>>> This has actually led to the disappearance of the
>> keyboard
>>>>>>> alts (the code
>>>>>>>> calls them mnemonics) for the main menus on the main SC
>>>>>>>>
>>>> screen
>>>>>>> for 'File'
>>>>>>>> and 'Help'. This is because the first listing correctly
>>>>>>>> has
>>>>>>> file=&File but
>>>>>>>> the whiteboard keys replace that with file=File. (Note
>>>>>>>> the
>>>>>> loss
>>>>>>> of the &).
>>>>>>>> There are other conflicts as well, I haven't made a
>> complete
>>>>>>> list yet.
>>>>>>>>>> Key names shouldn't be re-used like that, perhaps
>>>>>>>>>> all the
>>>>>>> whiteboard keys
>>>>>>>> should be renamed with a 'whiteboard-' prefix? Either
>>>>>>>> that
>> or
>>>>>>> they should
>>>>>>>> just use the same i18n keys that are alraedy defined.
>>>>>>>> (I
>>>>>> haven't
>>>>>>> used the
>>>>>>>> white board so I don't know what's going on here).
>>>>>>>>>> We have the same potential to have other conflicts
>>>>>>>>>>
>>>> elsewhere
>>>>>>> (and some
>>>>>>>> may even exist) unless there is a naming convention of
>>>>>>>> some
>>>>>> sort
>>>>>>> for i18n
>>>>>>>> keys. My suggestion is that anything that isn't global
>>>>>>>> or
>>>>>>> universal should
>>>>>>>> have some sort of prefix related to its
>>>>>>>> plugin/service/etc.
>>>>>>>>>> Alan
>>>>>>>>>>
>>>>>>>>>> --------------------------------------------------------
--
>>>>>>>>>>
>> --
>>>> -
>>>>>> --
>>>>>>> ------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@sip-
>>>>>>> communicator.dev.java.net>>> For additional commands,
>>>>>>> e-mail:
>>>>>>>>>> dev-help@sip-communicator.dev.java.net
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> ----------------------------------------------------------
--
>>>>>>>>
>> --
>>>> -
>>>>>> --
>>>>>>> ----
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@sip-
>>>>>>> communicator.dev.java.net> For additional commands,
>>>>>>> e-mail:
>>>> dev-
>>>>>>> help@sip-communicator.dev.java.net
>>>>>>>> ----------------------------------------------------------
--
>>>>>>>>
>> --
>>>> -
>>>>>> --
>>>>>>> ----
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@sip-
>>>>>>> communicator.dev.java.net> For additional commands,
>>>>>>> e-mail:
>>>> dev-
>>>>>>> help@sip-communicator.dev.java.net
>>>>>>> -----------------------------------------------------------
--
>>>>>>>
>> --
>>>> --
>>>>>> --
>>>>>>> -- To unsubscribe, e-mail: dev-unsubscribe@sip-
>>>>>> communicator.dev.java.net> For additional commands, e-mail:
>>>>>>
>> dev-
>>>>>> help@sip-
>>>>>>> communicator.dev.java.net
>>>>>>>
>>>>>> ------------------------------------------------------------
--
>>>>>>
>> --
>>>> ---
>>>>>> -- To unsubscribe, e-mail: dev-unsubscribe@sip-
>>>> communicator.dev.java.net>> For additional commands, e-mail:
>> dev-
>>>> help@sip-
>>>>>> communicator.dev.java.net
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------
--
>>>>>>
>> --
>>>> --------
>>>>>> ------------------------------------------------------------
--
>>>>>>
>> --
>>>> -----
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@sip-
>>>> communicator.dev.java.net>> For additional commands, e-mail:
>> dev-
>>>> help@sip-communicator.dev.java.net
>>>>
>>>>
>>>> --------------------------------------------------------------
--
>>>>
>> ---
>>>> -- To unsubscribe, e-mail: dev-unsubscribe@sip-
>> communicator.dev.java.net>> For additional commands, e-mail:
dev-
>> help@sip-
>>>> communicator.dev.java.net
>>>>
>>> ---------------------------------------------------------------
--
>>>
>> ----
>>> To unsubscribe, e-mail: dev-unsubscribe@sip-
>> communicator.dev.java.net> For additional commands, e-mail: dev-

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

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


#16

Hi Emil,

I know you've been busy but I was curious how the changes to the Resources strings were going, and if there's anything more I can do to help.

Alan

···

----- Original Message -----

From: Emil Ivov <emcho@sip-communicator.org>

Date: Thursday, August 14, 2008 10:47 am
Subject: Re: [sip-comm-dev] Update on changes to resources.properties

Hey Alan,

Alan C Kelly написа:
> Hi Emil,
>
> Here is the patch file.

Thanks!

> I was just thinking, should we be making the same prefix changes to
> images.properties and the other x.properties resource files?

Yes, absolutely! We've actually had a bug in one of the
images.properties files quite recently so I was also planning on
changing these.

Cheers
Emil
>
> Alan
>
> ----- Original Message ----- From: Emil Ivov
> <emcho@sip-communicator.org> Date: Thursday, August 14, 2008
9:35 am
> Subject: Re: [sip-comm-dev] Update on changes to
resources.properties>
>
>> Hey Alan,
>>
>> Yes please, I'd like to have the patch. Thanks for suggesting!.
>> I'll apply it and take it from there.
>>
>> Cheers Emil
>>
>> Alan C Kelly написа:
>>> Hi Emil,
>>>
>>> I've already replaced them for a number of the files, you you
>> like me to send you a patch file for the ones I've already done?
>>> Let me know. I've done a search and located all the usages of
>> getI18NString(), but changing them all one by one is tedious so if
>> you have a better idea, that would be great.
>>> Alan
>>>
>>> ----- Original Message ----- From: Emil Ivov
>>> <emcho@sip-communicator.org> Date: Thursday, August 14, 2008 9:22
>>> am Subject: Re: [sip-comm-dev] Update on changes to
>> resources.properties>
>>>> Hey Alan,
>>>>
>>>> I have some free time tomorrow so I was thinking of having a go
>>>>
>> at
>>>> thisissue. I'll commit your resources file and then replace all
>>>> the property strings. I think I see how we can do this
>>>> relatively easily so
>> I
>>>> hope it would not take more than a couple of hours.
>>>>
>>>> Thanks and will keep you posted.
>>>>
>>>> Cheers Emil
>>>>
>>>>
>>>>
>>>> Alan C Kelly написа:
>>>>> Update on the changes to resources.properties:
>>>>>
>>>>> Attached is the newly organized properties file, with the
>> bundle
>>>> prefixes added. I am sending this out as a preview of the
>> changes
>>>> Emil and I agreed upon. Any comments are welcome.
>>>>> I still have to complete the lengthy chore of adding the
>>>> prefixes every place getI18NString() is called in the code.
>> When
>>>> this is finished I will submit a patch.
>>>>> Unfortunately these changes mean that the various translation
>>>>>
>>>> files will have to be redone as well.
>>>>> Alan
>>>>>
>>>>> ----- Original Message ----- From: Alan C Kelly
>>>>> <akelly7@gmu.edu> Date: Friday, August 8, 2008 12:19 pm
>>>>> Subject: Re: [sip-comm-dev] Potentially major flaw in i18n
>>>> resources.properties>
>>>>>> Sounds good to me, I'll start working on it.
>>>>>>
>>>>>> ----- Original Message ----- From: Emil Ivov
>>>>>> <emcho@sip-communicator.org> Date: Wednesday, July 30, 2008
>>>>>> 5:09 am Subject: Re: [sip-comm-dev] Potentially major flaw
>>>>>> in i18n resources.properties
>>>>>>> Hey Alan,
>>>>>>>
>>>>>>> On Wed, Jul 30, 2008 at 5:11 AM, Alan Kelly
>> <akelly7@gmu.edu>
>>>> wrote:>>>> Emil,
>>>>>>>> That sounds like a nice solution. That's going to be a
>>>>>>>> lot
>> of
>>>>>>> changes to
>>>>>>>> make. I'm actually going to be going out of town in a
>> couple
>>>>>> of
>>>>>>> days so I'm
>>>>>>>> not likely to be able to tackle this before I leave. If
>>>>>>>>
>> it's
>>>>>>> still an issue
>>>>>>>> when I get back late next week, I'll try working with
>>>>>>>> it.
>>>>>>> If you'd like to do it then we'll make sure it stays open
>>>>>>>
>> for you.
>>>>>>>> Also, there are some values that would probably be
>>>>>>>> global
>> to
>>>>>> all
>>>>>>> of SC, what
>>>>>>>> would we call those? Just leave off the prefix? For
>> example,
>>>>>> how
>>>>>>> > listings will we really need for the word "Help"?
>>>>>>> It
>>>> seems
>>>>>> a
>>>>>>> > redundant.
>>>>>>>
>>>>>>> Good point. Guess we could follow the development
>>>>>>> convention
>>>>>> here and
>>>>>>> place "public" keys in "service.gui". The idea is that
>> >>>>> that's prefixed by service may be accessed in
an
>> inter-bundle and
>>>>>>> should remain stable.
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>> Emil
>>>>>>>> Alan
>>>>>>>>
>>>>>>>> -----Original Message----- From: Emil Ivov
>>>>>>>> [mailto:emcho@sip-communicator.org] Sent: Tuesday, July
>>>>>>>> 29, 2008 9:00 PM To: dev@sip-communicator.dev.java.net
>>>>>>>> Subject: Re: [sip-comm-dev] Potentially major flaw in
>>>>>>>> i18n resources.properties
>>>>>>>>
>>>>>>>> Oops, hit "Send" too quickly. What I wanted to add was
>>>>>>>> that
>>>> we
>>>>>>> could agree
>>>>>>>> on using naming conventions similar to that in the
>>>>>> configuration
>>>>>>> > which would give us something like:
>>
net.java.sip.communicator.[service|impl|plugin].bundlename.RESOURCE_NAME>>>> > In this case we can actually even skip the
>>>>>>> "net.java.sip.communicator"> prefix and only keep the
>>>>>>> part
>>>> that
>>>>>>> would change from one package to the
>>>>>>>> next. This way the whiteboard strings for example would
>>>>>>>>
>> have
>>>>>> the
>>>>>>> > form:
>>>>>>>> plugin.whiteboard.FILE=&File (The upper case would be
>>>>>>>> nice
>> to
>>>>>>> have but it's
>>>>>>>> not essential)
>>>>>>>>
>>>>>>>> How does this sound?
>>>>>>>>
>>>>>>>> Cheers Emil
>>>>>>>>
>>>>>>>> On Wed, Jul 30, 2008 at 2:52 AM, Emil Ivov <emcho@sip- > >>>>>>> communicator.org>> wrote:
>>>>>>>>> Hey Alan,
>>>>>>>>>
>>>>>>>>> Yes, that's a good point. I even remember actually
>>>> discussing the
>>>>>>>>> unification of resource strings with someone but I
>>>>>>>>> guess
>> no
>>>>>> one
>>>>>>> >> around to it.
>>>>>>>>> Interested in proposing a patch?
>>>>>>>>>
>>>>>>>>> Emil
>>>>>>>>>
>>>>>>>>> On Tue, Jul 29, 2008 at 8:21 PM, Alan C Kelly
>>>>>> <akelly7@gmu.edu>
>>>>>>> wrote:>>> Hi, me again...
>>>>>>>>>> I stumbled into a bug in the i18n properties files
>>>>>>>>>> in
>>>>>>>> resources\languages. The new whiteboard section is
>>>>>>>> reusing
>>>> key
>>>>>>> names that
>>>>>>>> have already been used, such as 'file' and 'about' This
>>>>>>>>
>>>> causes
>>>>>> a
>>>>>>> > problem when
>>>>>>> net.java.sip.communicator.impl.gui.i18n.Messages reads
>>>>>>> the
>>>>>>>> translation values. If there is more than one key with
>>>>>>>> the
>>>>>> same
>>>>>>> name, it
>>>>>>>> will read the value of the last key in the file.
>>>>>>>>>> This has actually led to the disappearance of the
>> keyboard
>>>>>>> alts (the code
>>>>>>>> calls them mnemonics) for the main menus on the main SC
>>>>>>>>
>>>> screen
>>>>>>> for 'File'
>>>>>>>> and 'Help'. This is because the first listing correctly
>>>>>>>> has
>>>>>>> file=&File but
>>>>>>>> the whiteboard keys replace that with file=File. (Note
>>>>>>>> the
>>>>>> loss
>>>>>>> of the &).
>>>>>>>> There are other conflicts as well, I haven't made a
>> complete
>>>>>>> list yet.
>>>>>>>>>> Key names shouldn't be re-used like that, perhaps
>>>>>>>>>> all the
>>>>>>> whiteboard keys
>>>>>>>> should be renamed with a 'whiteboard-' prefix? Either
>>>>>>>> that
>> or
>>>>>>> they should
>>>>>>>> just use the same i18n keys that are alraedy defined.
>>>>>>>> (I
>>>>>> haven't
>>>>>>> used the
>>>>>>>> white board so I don't know what's going on here).
>>>>>>>>>> We have the same potential to have other conflicts
>>>>>>>>>>
>>>> elsewhere
>>>>>>> (and some
>>>>>>>> may even exist) unless there is a naming convention of
>>>>>>>> some
>>>>>> sort
>>>>>>> for i18n
>>>>>>>> keys. My suggestion is that anything that isn't global
>>>>>>>> or
>>>>>>> universal should
>>>>>>>> have some sort of prefix related to its
>>>>>>>> plugin/service/etc.
>>>>>>>>>> Alan
>>>>>>>>>>
>>>>>>>>>> --------------------------------------------------------
--
>>>>>>>>>>
>> --
>>>> -
>>>>>> --
>>>>>>> ------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@sip-
>>>>>>> communicator.dev.java.net>>> For additional commands,
>>>>>>> e-mail:
>>>>>>>>>> dev-help@sip-communicator.dev.java.net
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> ----------------------------------------------------------
--
>>>>>>>>
>> --
>>>> -
>>>>>> --
>>>>>>> ----
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@sip-
>>>>>>> communicator.dev.java.net> For additional commands,
>>>>>>> e-mail:
>>>> dev-
>>>>>>> help@sip-communicator.dev.java.net
>>>>>>>> ----------------------------------------------------------
--
>>>>>>>>
>> --
>>>> -
>>>>>> --
>>>>>>> ----
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@sip-
>>>>>>> communicator.dev.java.net> For additional commands,
>>>>>>> e-mail:
>>>> dev-
>>>>>>> help@sip-communicator.dev.java.net
>>>>>>> -----------------------------------------------------------
--
>>>>>>>
>> --
>>>> --
>>>>>> --
>>>>>>> -- To unsubscribe, e-mail: dev-unsubscribe@sip-
>>>>>> communicator.dev.java.net> For additional commands, e-mail:
>>>>>>
>> dev-
>>>>>> help@sip-
>>>>>>> communicator.dev.java.net
>>>>>>>
>>>>>> ------------------------------------------------------------
--
>>>>>>
>> --
>>>> ---
>>>>>> -- To unsubscribe, e-mail: dev-unsubscribe@sip-
>>>> communicator.dev.java.net>> For additional commands, e-mail:
>> dev-
>>>> help@sip-
>>>>>> communicator.dev.java.net
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------
--
>>>>>>
>> --
>>>> --------
>>>>>> ------------------------------------------------------------
--
>>>>>>
>> --
>>>> -----
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@sip-
>>>> communicator.dev.java.net>> For additional commands, e-mail:
>> dev-
>>>> help@sip-communicator.dev.java.net
>>>>
>>>>
>>>> --------------------------------------------------------------
--
>>>>
>> ---
>>>> -- To unsubscribe, e-mail: dev-unsubscribe@sip-
>> communicator.dev.java.net>> For additional commands, e-mail:
dev-
>> help@sip-
>>>> communicator.dev.java.net
>>>>
>>> ---------------------------------------------------------------
--
>>>
>> ----
>>> To unsubscribe, e-mail: dev-unsubscribe@sip-
>> communicator.dev.java.net> For additional commands, e-mail: dev-

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

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

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


#17

Hi Emil,

I forget where we left this... did we give up on it for a reason or did it
just slip through the cracks?

Thanks,

Alan

···

-----Original Message-----

From: Emil Ivov [mailto:emcho@sip-communicator.org]

Sent: Thursday, August 14, 2008 10:47 AM
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Update on changes to resources.properties

Hey Alan,

Alan C Kelly написа:

Hi Emil,

Here is the patch file.

Thanks!

I was just thinking, should we be making the same prefix changes to
images.properties and the other x.properties resource files?

Yes, absolutely! We've actually had a bug in one of the images.properties
files quite recently so I was also planning on changing these.

Cheers
Emil

Alan

----- Original Message ----- From: Emil Ivov
<emcho@sip-communicator.org> Date: Thursday, August 14, 2008 9:35 am
Subject: Re: [sip-comm-dev] Update on changes to resources.properties

Hey Alan,

Yes please, I'd like to have the patch. Thanks for suggesting!.
I'll apply it and take it from there.

Cheers Emil

Alan C Kelly написа:

Hi Emil,

I've already replaced them for a number of the files, you you

like me to send you a patch file for the ones I've already done?

Let me know. I've done a search and located all the usages of

getI18NString(), but changing them all one by one is tedious so if
you have a better idea, that would be great.

Alan

----- Original Message ----- From: Emil Ivov
<emcho@sip-communicator.org> Date: Thursday, August 14, 2008 9:22 am
Subject: Re: [sip-comm-dev] Update on changes to

resources.properties>

Hey Alan,

I have some free time tomorrow so I was thinking of having a go

at

thisissue. I'll commit your resources file and then replace all
the property strings. I think I see how we can do this relatively
easily so

I

hope it would not take more than a couple of hours.

Thanks and will keep you posted.

Cheers Emil

Alan C Kelly написа:

Update on the changes to resources.properties:

Attached is the newly organized properties file, with the

bundle

prefixes added. I am sending this out as a preview of the

changes

Emil and I agreed upon. Any comments are welcome.

I still have to complete the lengthy chore of adding the

prefixes every place getI18NString() is called in the code.

When

this is finished I will submit a patch.

Unfortunately these changes mean that the various translation

files will have to be redone as well.

Alan

----- Original Message ----- From: Alan C Kelly <akelly7@gmu.edu>
Date: Friday, August 8, 2008 12:19 pm
Subject: Re: [sip-comm-dev] Potentially major flaw in i18n

resources.properties>

Sounds good to me, I'll start working on it.

----- Original Message ----- From: Emil Ivov
<emcho@sip-communicator.org> Date: Wednesday, July 30, 2008
5:09 am Subject: Re: [sip-comm-dev] Potentially major flaw in
i18n resources.properties

Hey Alan,

On Wed, Jul 30, 2008 at 5:11 AM, Alan Kelly

<akelly7@gmu.edu>

wrote:>>>> Emil,

That sounds like a nice solution. That's going to be a lot

of

changes to

make. I'm actually going to be going out of town in a

couple

of

days so I'm

not likely to be able to tackle this before I leave. If

it's

still an issue

when I get back late next week, I'll try working with it.

If you'd like to do it then we'll make sure it stays open

for you.

Also, there are some values that would probably be
global

to

all

of SC, what

would we call those? Just leave off the prefix? For

example,

how

> listings will we really need for the word "Help"?
It

seems

a

> redundant.

Good point. Guess we could follow the development
convention

here and

place "public" keys in "service.gui". The idea is that

>>>>> that's prefixed by service may be accessed in an
inter-bundle and

should remain stable.

What do you think?

Emil

Alan

-----Original Message----- From: Emil Ivov
[mailto:emcho@sip-communicator.org] Sent: Tuesday, July
29, 2008 9:00 PM To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Potentially major flaw in
i18n resources.properties

Oops, hit "Send" too quickly. What I wanted to add was
that

we

could agree

on using naming conventions similar to that in the

configuration

> which would give us something like:

net.java.sip.communicator.[service|impl|plugin].bundlename.RESOURCE_NAME>>

> In this case we can actually even skip the

"net.java.sip.communicator"> prefix and only keep the
part

that

would change from one package to the

next. This way the whiteboard strings for example would

have

the

> form:

plugin.whiteboard.FILE=&File (The upper case would be
nice

to

have but it's

not essential)

How does this sound?

Cheers Emil

On Wed, Jul 30, 2008 at 2:52 AM, Emil Ivov <emcho@sip- >>>>>>> communicator.org>> wrote:

Hey Alan,

Yes, that's a good point. I even remember actually

discussing the

unification of resource strings with someone but I
guess

no

one

>> around to it.

Interested in proposing a patch?

Emil

On Tue, Jul 29, 2008 at 8:21 PM, Alan C Kelly

<akelly7@gmu.edu>

wrote:>>> Hi, me again...

I stumbled into a bug in the i18n properties files
in

resources\languages. The new whiteboard section is
reusing

key

names that

have already been used, such as 'file' and 'about' This

causes

a

> problem when
net.java.sip.communicator.impl.gui.i18n.Messages reads
the

translation values. If there is more than one key with
the

same

name, it

will read the value of the last key in the file.

This has actually led to the disappearance of the

keyboard

alts (the code

calls them mnemonics) for the main menus on the main SC

screen

for 'File'

and 'Help'. This is because the first listing correctly
has

file=&File but

the whiteboard keys replace that with file=File. (Note
the

loss

of the &).

There are other conflicts as well, I haven't made a

complete

list yet.

Key names shouldn't be re-used like that, perhaps
all the

whiteboard keys

should be renamed with a 'whiteboard-' prefix? Either
that

or

they should

just use the same i18n keys that are alraedy defined.
(I

haven't

used the

white board so I don't know what's going on here).

We have the same potential to have other conflicts

elsewhere

(and some

may even exist) unless there is a naming convention of
some

sort

for i18n

keys. My suggestion is that anything that isn't global
or

universal should

have some sort of prefix related to its
plugin/service/etc.

Alan

----------------------------------------------------------

--

-

--

------

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net>>> For additional commands,
e-mail:

dev-help@sip-communicator.dev.java.net

------------------------------------------------------------

--

-

--

----

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net> For additional commands,
e-mail:

dev-

help@sip-communicator.dev.java.net

------------------------------------------------------------

--

-

--

----

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net> For additional commands,
e-mail:

dev-

help@sip-communicator.dev.java.net
-------------------------------------------------------------

--

--

--

-- To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net> For additional commands, e-mail:

dev-

help@sip-

communicator.dev.java.net

--------------------------------------------------------------

--

---

-- To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net>> For additional commands, e-mail:

dev-

help@sip-

communicator.dev.java.net

--------------------------------------------------------------

--

--------

--------------------------------------------------------------

--

-----

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net>> For additional commands, e-mail:

dev-

help@sip-communicator.dev.java.net

----------------------------------------------------------------

---

-- To unsubscribe, e-mail: dev-unsubscribe@sip-

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

communicator.dev.java.net

-----------------------------------------------------------------

----

To unsubscribe, e-mail: dev-unsubscribe@sip-

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

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

------------------------------------------------------------------------

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

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

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


#18

Hey Alan,

Still on my todo list. Apologies. Would really really try to handle it
this week.

Emil

Alan Kelly написа:

···

Hi Emil,

I forget where we left this... did we give up on it for a reason or did it
just slip through the cracks?

Thanks,

Alan

-----Original Message-----
From: Emil Ivov [mailto:emcho@sip-communicator.org]
Sent: Thursday, August 14, 2008 10:47 AM
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Update on changes to resources.properties

Hey Alan,

Alan C Kelly написа:

Hi Emil,

Here is the patch file.

Thanks!

I was just thinking, should we be making the same prefix changes to
images.properties and the other x.properties resource files?

Yes, absolutely! We've actually had a bug in one of the images.properties
files quite recently so I was also planning on changing these.

Cheers
Emil

Alan

----- Original Message ----- From: Emil Ivov
<emcho@sip-communicator.org> Date: Thursday, August 14, 2008 9:35 am
Subject: Re: [sip-comm-dev] Update on changes to resources.properties

Hey Alan,

Yes please, I'd like to have the patch. Thanks for suggesting!.
I'll apply it and take it from there.

Cheers Emil

Alan C Kelly написа:

Hi Emil,

I've already replaced them for a number of the files, you you

like me to send you a patch file for the ones I've already done?

Let me know. I've done a search and located all the usages of

getI18NString(), but changing them all one by one is tedious so if
you have a better idea, that would be great.

Alan

----- Original Message ----- From: Emil Ivov
<emcho@sip-communicator.org> Date: Thursday, August 14, 2008 9:22 am
Subject: Re: [sip-comm-dev] Update on changes to

resources.properties>

Hey Alan,

I have some free time tomorrow so I was thinking of having a go

at

thisissue. I'll commit your resources file and then replace all
the property strings. I think I see how we can do this relatively
easily so

I

hope it would not take more than a couple of hours.

Thanks and will keep you posted.

Cheers Emil

Alan C Kelly написа:

Update on the changes to resources.properties:

Attached is the newly organized properties file, with the

bundle

prefixes added. I am sending this out as a preview of the

changes

Emil and I agreed upon. Any comments are welcome.

I still have to complete the lengthy chore of adding the

prefixes every place getI18NString() is called in the code.

When

this is finished I will submit a patch.

Unfortunately these changes mean that the various translation

files will have to be redone as well.

Alan

----- Original Message ----- From: Alan C Kelly <akelly7@gmu.edu>
Date: Friday, August 8, 2008 12:19 pm
Subject: Re: [sip-comm-dev] Potentially major flaw in i18n

resources.properties>

Sounds good to me, I'll start working on it.

----- Original Message ----- From: Emil Ivov
<emcho@sip-communicator.org> Date: Wednesday, July 30, 2008
5:09 am Subject: Re: [sip-comm-dev] Potentially major flaw in
i18n resources.properties

Hey Alan,

On Wed, Jul 30, 2008 at 5:11 AM, Alan Kelly

<akelly7@gmu.edu>

wrote:>>>> Emil,

That sounds like a nice solution. That's going to be a lot

of

changes to

make. I'm actually going to be going out of town in a

couple

of

days so I'm

not likely to be able to tackle this before I leave. If

it's

still an issue

when I get back late next week, I'll try working with it.

If you'd like to do it then we'll make sure it stays open

for you.

Also, there are some values that would probably be
global

to

all

of SC, what

would we call those? Just leave off the prefix? For

example,

how

> listings will we really need for the word "Help"?
It

seems

a

> redundant.

Good point. Guess we could follow the development
convention

here and

place "public" keys in "service.gui". The idea is that

>>>>> that's prefixed by service may be accessed in an
inter-bundle and

should remain stable.

What do you think?

Emil

Alan

-----Original Message----- From: Emil Ivov
[mailto:emcho@sip-communicator.org] Sent: Tuesday, July
29, 2008 9:00 PM To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Potentially major flaw in
i18n resources.properties

Oops, hit "Send" too quickly. What I wanted to add was
that

we

could agree

on using naming conventions similar to that in the

configuration

> which would give us something like:

net.java.sip.communicator.[service|impl|plugin].bundlename.RESOURCE_NAME>>

In this case we can actually even skip the

"net.java.sip.communicator"> prefix and only keep the
part

that

would change from one package to the

next. This way the whiteboard strings for example would

have

the

> form:

plugin.whiteboard.FILE=&File (The upper case would be
nice

to

have but it's

not essential)

How does this sound?

Cheers Emil

On Wed, Jul 30, 2008 at 2:52 AM, Emil Ivov <emcho@sip- >>>>>>>> communicator.org>> wrote:

Hey Alan,

Yes, that's a good point. I even remember actually

discussing the

unification of resource strings with someone but I
guess

no

one

>> around to it.

Interested in proposing a patch?

Emil

On Tue, Jul 29, 2008 at 8:21 PM, Alan C Kelly

<akelly7@gmu.edu>

wrote:>>> Hi, me again...

I stumbled into a bug in the i18n properties files
in

resources\languages. The new whiteboard section is
reusing

key

names that

have already been used, such as 'file' and 'about' This

causes

a

> problem when
net.java.sip.communicator.impl.gui.i18n.Messages reads
the

translation values. If there is more than one key with
the

same

name, it

will read the value of the last key in the file.

This has actually led to the disappearance of the

keyboard

alts (the code

calls them mnemonics) for the main menus on the main SC

screen

for 'File'

and 'Help'. This is because the first listing correctly
has

file=&File but

the whiteboard keys replace that with file=File. (Note
the

loss

of the &).

There are other conflicts as well, I haven't made a

complete

list yet.

Key names shouldn't be re-used like that, perhaps
all the

whiteboard keys

should be renamed with a 'whiteboard-' prefix? Either
that

or

they should

just use the same i18n keys that are alraedy defined.
(I

haven't

used the

white board so I don't know what's going on here).

We have the same potential to have other conflicts

elsewhere

(and some

may even exist) unless there is a naming convention of
some

sort

for i18n

keys. My suggestion is that anything that isn't global
or

universal should

have some sort of prefix related to its
plugin/service/etc.

Alan

----------------------------------------------------------

--

-

--

------

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net>>> For additional commands,
e-mail:

dev-help@sip-communicator.dev.java.net

------------------------------------------------------------

--

-

--

----

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net> For additional commands,
e-mail:

dev-

help@sip-communicator.dev.java.net

------------------------------------------------------------

--

-

--

----

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net> For additional commands,
e-mail:

dev-

help@sip-communicator.dev.java.net
-------------------------------------------------------------

--

--

--

-- To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net> For additional commands, e-mail:

dev-

help@sip-

communicator.dev.java.net

--------------------------------------------------------------

--

---

-- To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net>> For additional commands, e-mail:

dev-

help@sip-

communicator.dev.java.net

--------------------------------------------------------------

--

--------

--------------------------------------------------------------

--

-----

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net>> For additional commands, e-mail:

dev-

help@sip-communicator.dev.java.net

----------------------------------------------------------------

---

-- To unsubscribe, e-mail: dev-unsubscribe@sip-

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

communicator.dev.java.net

-----------------------------------------------------------------

----

To unsubscribe, e-mail: dev-unsubscribe@sip-

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

------------------------------------------------------------------------

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

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

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

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


#19

Ok, no problem. I just realized we had never resolved this.

···

-----Original Message-----

From: Emil Ivov [mailto:emil@sip-communicator.org] On Behalf Of Emil Ivov

Sent: Wednesday, October 29, 2008 9:28 AM
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Update on changes to resources.properties

Hey Alan,

Still on my todo list. Apologies. Would really really try to handle it this
week.

Emil

Alan Kelly написа:

Hi Emil,

I forget where we left this... did we give up on it for a reason or
did it just slip through the cracks?

Thanks,

Alan

-----Original Message-----
From: Emil Ivov [mailto:emcho@sip-communicator.org]
Sent: Thursday, August 14, 2008 10:47 AM
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Update on changes to resources.properties

Hey Alan,

Alan C Kelly написа:

Hi Emil,

Here is the patch file.

Thanks!

I was just thinking, should we be making the same prefix changes to
images.properties and the other x.properties resource files?

Yes, absolutely! We've actually had a bug in one of the
images.properties files quite recently so I was also planning on changing

these.

Cheers
Emil

Alan

----- Original Message ----- From: Emil Ivov
<emcho@sip-communicator.org> Date: Thursday, August 14, 2008 9:35 am
Subject: Re: [sip-comm-dev] Update on changes to resources.properties

Hey Alan,

Yes please, I'd like to have the patch. Thanks for suggesting!.
I'll apply it and take it from there.

Cheers Emil

Alan C Kelly написа:

Hi Emil,

I've already replaced them for a number of the files, you you

like me to send you a patch file for the ones I've already done?

Let me know. I've done a search and located all the usages of

getI18NString(), but changing them all one by one is tedious so if
you have a better idea, that would be great.

Alan

----- Original Message ----- From: Emil Ivov
<emcho@sip-communicator.org> Date: Thursday, August 14, 2008 9:22
am
Subject: Re: [sip-comm-dev] Update on changes to

resources.properties>

Hey Alan,

I have some free time tomorrow so I was thinking of having a go

at

thisissue. I'll commit your resources file and then replace all
the property strings. I think I see how we can do this relatively
easily so

I

hope it would not take more than a couple of hours.

Thanks and will keep you posted.

Cheers Emil

Alan C Kelly написа:

Update on the changes to resources.properties:

Attached is the newly organized properties file, with the

bundle

prefixes added. I am sending this out as a preview of the

changes

Emil and I agreed upon. Any comments are welcome.

I still have to complete the lengthy chore of adding the

prefixes every place getI18NString() is called in the code.

When

this is finished I will submit a patch.

Unfortunately these changes mean that the various translation

files will have to be redone as well.

Alan

----- Original Message ----- From: Alan C Kelly <akelly7@gmu.edu>
Date: Friday, August 8, 2008 12:19 pm
Subject: Re: [sip-comm-dev] Potentially major flaw in i18n

resources.properties>

Sounds good to me, I'll start working on it.

----- Original Message ----- From: Emil Ivov
<emcho@sip-communicator.org> Date: Wednesday, July 30, 2008
5:09 am Subject: Re: [sip-comm-dev] Potentially major flaw in
i18n resources.properties

Hey Alan,

On Wed, Jul 30, 2008 at 5:11 AM, Alan Kelly

<akelly7@gmu.edu>

wrote:>>>> Emil,

That sounds like a nice solution. That's going to be a lot

of

changes to

make. I'm actually going to be going out of town in a

couple

of

days so I'm

not likely to be able to tackle this before I leave. If

it's

still an issue

when I get back late next week, I'll try working with it.

If you'd like to do it then we'll make sure it stays open

for you.

Also, there are some values that would probably be global

to

all

of SC, what

would we call those? Just leave off the prefix? For

example,

how

> listings will we really need for the word "Help"?
It

seems

a

> redundant.

Good point. Guess we could follow the development convention

here and

place "public" keys in "service.gui". The idea is that

>>>>> that's prefixed by service may be accessed in an
inter-bundle and

should remain stable.

What do you think?

Emil

Alan

-----Original Message----- From: Emil Ivov
[mailto:emcho@sip-communicator.org] Sent: Tuesday, July 29,
2008 9:00 PM To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Potentially major flaw in i18n
resources.properties

Oops, hit "Send" too quickly. What I wanted to add was that

we

could agree

on using naming conventions similar to that in the

configuration

> which would give us something like:

net.java.sip.communicator.[service|impl|plugin].bundlename.RESOURCE_NA
>>

In this case we can actually even skip the

"net.java.sip.communicator"> prefix and only keep the part

that

would change from one package to the

next. This way the whiteboard strings for example would

have

the

> form:

plugin.whiteboard.FILE=&File (The upper case would be nice

to

have but it's

not essential)

How does this sound?

Cheers Emil

On Wed, Jul 30, 2008 at 2:52 AM, Emil Ivov <emcho@sip- >>>>>>>> communicator.org>> wrote:

Hey Alan,

Yes, that's a good point. I even remember actually

discussing the

unification of resource strings with someone but I guess

no

one

>> around to it.

Interested in proposing a patch?

Emil

On Tue, Jul 29, 2008 at 8:21 PM, Alan C Kelly

<akelly7@gmu.edu>

wrote:>>> Hi, me again...

I stumbled into a bug in the i18n properties files in

resources\languages. The new whiteboard section is reusing

key

names that

have already been used, such as 'file' and 'about' This

causes

a

> problem when
net.java.sip.communicator.impl.gui.i18n.Messages reads the

translation values. If there is more than one key with the

same

name, it

will read the value of the last key in the file.

This has actually led to the disappearance of the

keyboard

alts (the code

calls them mnemonics) for the main menus on the main SC

screen

for 'File'

and 'Help'. This is because the first listing correctly has

file=&File but

the whiteboard keys replace that with file=File. (Note the

loss

of the &).

There are other conflicts as well, I haven't made a

complete

list yet.

Key names shouldn't be re-used like that, perhaps all the

whiteboard keys

should be renamed with a 'whiteboard-' prefix? Either that

or

they should

just use the same i18n keys that are alraedy defined.
(I

haven't

used the

white board so I don't know what's going on here).

We have the same potential to have other conflicts

elsewhere

(and some

may even exist) unless there is a naming convention of some

sort

for i18n

keys. My suggestion is that anything that isn't global or

universal should

have some sort of prefix related to its plugin/service/etc.

Alan

----------------------------------------------------------

--

-

--

------

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net>>> For additional commands,
e-mail:

dev-help@sip-communicator.dev.java.net

------------------------------------------------------------

--

-

--

----

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net> For additional commands,
e-mail:

dev-

help@sip-communicator.dev.java.net

------------------------------------------------------------

--

-

--

----

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net> For additional commands,
e-mail:

dev-

help@sip-communicator.dev.java.net
-------------------------------------------------------------

--

--

--

-- To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net> For additional commands, e-mail:

dev-

help@sip-

communicator.dev.java.net

--------------------------------------------------------------

--

---

-- To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net>> For additional commands, e-mail:

dev-

help@sip-

communicator.dev.java.net

--------------------------------------------------------------

--

--------

--------------------------------------------------------------

--

-----

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net>> For additional commands, e-mail:

dev-

help@sip-communicator.dev.java.net

----------------------------------------------------------------

---

-- To unsubscribe, e-mail: dev-unsubscribe@sip-

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

communicator.dev.java.net

-----------------------------------------------------------------

----

To unsubscribe, e-mail: dev-unsubscribe@sip-

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

--------------------------------------------------------------------
----

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

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

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

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

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


#20

Hi Alan,

I have started working on the resource convention that you and Emil have
discussed some time ago. I should say that you have done an amazing job in your patches. Thanks!

The code has changed from the date you send your patches, so it was a little tricky to apply them as they are, but I think I've done it now for all colors, settings and images. I've also modified all the related sources accordingly. As I had to apply patches manually, because of code differences, I've also took advantage to change some property names in order to make them more comprehensible.

I'm now continuing with the internationalization resources. They're also coming soon.

Thanks again!
Yana

Alan Kelly wrote:

···

Ok, no problem. I just realized we had never resolved this.

-----Original Message-----
From: Emil Ivov [mailto:emil@sip-communicator.org] On Behalf Of Emil Ivov
Sent: Wednesday, October 29, 2008 9:28 AM
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Update on changes to resources.properties

Hey Alan,

Still on my todo list. Apologies. Would really really try to handle it this
week.

Emil

Alan Kelly ������:

Hi Emil,

I forget where we left this... did we give up on it for a reason or did it just slip through the cracks?

Thanks,

Alan

-----Original Message-----
From: Emil Ivov [mailto:emcho@sip-communicator.org]
Sent: Thursday, August 14, 2008 10:47 AM
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Update on changes to resources.properties

Hey Alan,

Alan C Kelly ������:

Hi Emil,

Here is the patch file.

Thanks!

I was just thinking, should we be making the same prefix changes to images.properties and the other x.properties resource files?

Yes, absolutely! We've actually had a bug in one of the images.properties files quite recently so I was also planning on changing

these.

Cheers
Emil

Alan

----- Original Message ----- From: Emil Ivov <emcho@sip-communicator.org> Date: Thursday, August 14, 2008 9:35 am
Subject: Re: [sip-comm-dev] Update on changes to resources.properties

Hey Alan,

Yes please, I'd like to have the patch. Thanks for suggesting!.
I'll apply it and take it from there.

Cheers Emil

Alan C Kelly ������:

Hi Emil,

I've already replaced them for a number of the files, you you

like me to send you a patch file for the ones I've already done?

Let me know. I've done a search and located all the usages of

getI18NString(), but changing them all one by one is tedious so if you have a better idea, that would be great.

Alan

----- Original Message ----- From: Emil Ivov <emcho@sip-communicator.org> Date: Thursday, August 14, 2008 9:22 am
Subject: Re: [sip-comm-dev] Update on changes to

resources.properties>

Hey Alan,

I have some free time tomorrow so I was thinking of having a go

at

thisissue. I'll commit your resources file and then replace all the property strings. I think I see how we can do this relatively easily so

I

hope it would not take more than a couple of hours.

Thanks and will keep you posted.

Cheers Emil

Alan C Kelly ������:

Update on the changes to resources.properties:

Attached is the newly organized properties file, with the

bundle

prefixes added. I am sending this out as a preview of the

changes

Emil and I agreed upon. Any comments are welcome.

I still have to complete the lengthy chore of adding the

prefixes every place getI18NString() is called in the code.

When

this is finished I will submit a patch.

Unfortunately these changes mean that the various translation

files will have to be redone as well.

Alan

----- Original Message ----- From: Alan C Kelly <akelly7@gmu.edu>
Date: Friday, August 8, 2008 12:19 pm
Subject: Re: [sip-comm-dev] Potentially major flaw in i18n

resources.properties>

Sounds good to me, I'll start working on it.

----- Original Message ----- From: Emil Ivov <emcho@sip-communicator.org> Date: Wednesday, July 30, 2008
5:09 am Subject: Re: [sip-comm-dev] Potentially major flaw in i18n resources.properties

Hey Alan,

On Wed, Jul 30, 2008 at 5:11 AM, Alan Kelly

<akelly7@gmu.edu>

wrote:>>>> Emil,

That sounds like a nice solution. That's going to be a lot

of

changes to

make. I'm actually going to be going out of town in a

couple

of

days so I'm

not likely to be able to tackle this before I leave. If

it's

still an issue

when I get back late next week, I'll try working with it.

If you'd like to do it then we'll make sure it stays open

for you.

Also, there are some values that would probably be global

to

all

of SC, what

would we call those? Just leave off the prefix? For

example,

how

> listings will we really need for the word "Help"?
It

seems

a

> redundant.

Good point. Guess we could follow the development convention

here and

place "public" keys in "service.gui". The idea is that

>>>>> that's prefixed by service may be accessed in an
inter-bundle and

should remain stable.

What do you think?

Emil

Alan

-----Original Message----- From: Emil Ivov [mailto:emcho@sip-communicator.org] Sent: Tuesday, July 29, 2008 9:00 PM To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Potentially major flaw in i18n resources.properties

Oops, hit "Send" too quickly. What I wanted to add was that

we

could agree

on using naming conventions similar to that in the

configuration

> which would give us something like:

net.java.sip.communicator.[service|impl|plugin].bundlename.RESOURCE_NA
>>

In this case we can actually even skip the

"net.java.sip.communicator"> prefix and only keep the part

that

would change from one package to the

next. This way the whiteboard strings for example would

have

the

> form:

plugin.whiteboard.FILE=&File (The upper case would be nice

to

have but it's

not essential)

How does this sound?

Cheers Emil

On Wed, Jul 30, 2008 at 2:52 AM, Emil Ivov <emcho@sip- >>>>>>>>> communicator.org>> wrote:

Hey Alan,

Yes, that's a good point. I even remember actually

discussing the

unification of resource strings with someone but I guess

no

one

>> around to it.

Interested in proposing a patch?

Emil

On Tue, Jul 29, 2008 at 8:21 PM, Alan C Kelly

<akelly7@gmu.edu>

wrote:>>> Hi, me again...

I stumbled into a bug in the i18n properties files in

resources\languages. The new whiteboard section is reusing

key

names that

have already been used, such as 'file' and 'about' This

causes

a

> problem when
net.java.sip.communicator.impl.gui.i18n.Messages reads the

translation values. If there is more than one key with the

same

name, it

will read the value of the last key in the file.

This has actually led to the disappearance of the

keyboard

alts (the code

calls them mnemonics) for the main menus on the main SC

screen

for 'File'

and 'Help'. This is because the first listing correctly has

file=&File but

the whiteboard keys replace that with file=File. (Note the

loss

of the &).

There are other conflicts as well, I haven't made a

complete

list yet.

Key names shouldn't be re-used like that, perhaps all the

whiteboard keys

should be renamed with a 'whiteboard-' prefix? Either that

or

they should

just use the same i18n keys that are alraedy defined.
(I

haven't

used the

white board so I don't know what's going on here).

We have the same potential to have other conflicts

elsewhere

(and some

may even exist) unless there is a naming convention of some

sort

for i18n

keys. My suggestion is that anything that isn't global or

universal should

have some sort of prefix related to its plugin/service/etc.

Alan

----------------------------------------------------------

--

-

--

------

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net>>> For additional commands,
e-mail:

dev-help@sip-communicator.dev.java.net

------------------------------------------------------------

--

-

--

----

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net> For additional commands,
e-mail:

dev-

help@sip-communicator.dev.java.net

------------------------------------------------------------

--

-

--

----

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net> For additional commands,
e-mail:

dev-

help@sip-communicator.dev.java.net
-------------------------------------------------------------

--

--

--

-- To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net> For additional commands, e-mail:

dev-

help@sip-

communicator.dev.java.net

--------------------------------------------------------------

--

---

-- To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net>> For additional commands, e-mail:

dev-

help@sip-

communicator.dev.java.net

--------------------------------------------------------------

--

--------

--------------------------------------------------------------

--

-----

To unsubscribe, e-mail: dev-unsubscribe@sip-

communicator.dev.java.net>> For additional commands, e-mail:

dev-

help@sip-communicator.dev.java.net

----------------------------------------------------------------

---

-- To unsubscribe, e-mail: dev-unsubscribe@sip-

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

communicator.dev.java.net

-----------------------------------------------------------------

----

To unsubscribe, e-mail: dev-unsubscribe@sip-

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

--------------------------------------------------------------------
----

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

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

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

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

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

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