Re: [PROPOSAL] Tomcat 10: rename language bundles

[Michael Osipov <mi...@apache.org>]

Am 2020-01-30 um 18:41 schrieb Konstantin Kolinko:
> ср, 29 янв. 2020 г. в 00:08, Michael Osipov <mi...@apache.org>:
>>
>> Folks,
>>
>> I recently worked on some localization issues and noticed that, in my
>> opinion, these JARs are incorrectly named:
>>
>>> tomcat-i18n-cs.jar
>>> tomcat-i18n-de.jar
>>> tomcat-i18n-es.jar
>>> tomcat-i18n-fr.jar
>>> tomcat-i18n-ja.jar
>>> tomcat-i18n-ko.jar
>>> tomcat-i18n-pt-BR.jar
>>> tomcat-i18n-ru.jar
>>> tomcat-i18n-zh-CN.jar
>>
>> Most people confuse I18N with L10N -- but they are distinct. According
>> to Mozilla [1] Tomcat is internationalized and provides localization
>> with those bundles. As far as I understand that, they should be
>>
>> either tomcat-l10n-<locale>.jar or tomcat-nls-<locale>.jar
>>
>> [...]
>>
>> Comments?
> 
> 1. Overall, I am not convinced.
> 
> I think that for an average foreigner a discussion about what term is
> better makes little sense. I know people for whom those words are hard
> to pronounce and are a little obscure.
> 
> Does changing one "obscure" word with another makes life easier? How?
> Does it help to reach some wider audience?
> 
> I think that it would be better to keep it simple (KISS) and continue
> using the existing historic naming pattern.
> 
> I am really proud of 20+ years of history of our project. If there are
> some things there that are not proper [American] English, it just
> means that there are different people involved with the project, and
> it is a good sign.
> 
> (Being too strict about language is a barrier that may reject people.)

For those who don't know both, they don't care. For those who know care 
to make it right/consistent. I see no downsides to make it right.

This has nothing to do with American, British, You Name It English. It 
is simply about consistent naming.

> 2. In multi-module projects built with Apache Maven, one widely used
> naming convention is to name artifacts produced by the nested modules
> as <parentId>-<foo>.
> 
> E.g., a discussion:
> https://stackoverflow.com/questions/9435460/maven-naming-conventions-for-hierarchical-multiple-module-projects
> 
> I mean that the current artifact names of "tomcat-i18n-<locale>" can
> be interpreted as module "<locale>" in a parent project "tomcat-i18n".
> It means that those artifacts are part of internationalization effort
> in Tomcat.

I don't see how this is related?! Nor did I bring up to do any migration 
to Maven or its naming scheme.

> 3. Overall, my vote for this proposal is -0.5.
> 
> It is not a veto, but I do not like it.

So you generally do not object, but don't see a need for?

M


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: [PROPOSAL] Tomcat 10: rename language bundles

[Rémy Maucherat <re...@apache.org>]

On Mon, Feb 3, 2020 at 10:13 AM Konstantin Kolinko <kn...@gmail.com>
wrote:

> сб, 1 февр. 2020 г. в 16:31, Michael Osipov <mi...@apache.org>:
> >
> > Am 2020-01-30 um 18:41 schrieb Konstantin Kolinko:
> > > ср, 29 янв. 2020 г. в 00:08, Michael Osipov <mi...@apache.org>:
> > >
> > > [...]
> > >
> > > (Being too strict about language is a barrier that may reject people.)
> >
> > For those who don't know both, they don't care. For those who know care
> > to make it right/consistent. I see no downsides to make it right.
> >
> > This has nothing to do with American, British, You Name It English. It
> > is simply about consistent naming.
>
> I see no positive sides in the proposed renaming,
> and I do not feel it to be a right thing.
>

It's hard to argue the usefulness of the fix is limited. I'm not going to
-1 it though since the problem might be my fault (can't remember, that's
convenient :) ).

Rémy


>
> Some downsides were already mentioned by others. I will write down a
> more complete list below.
>
> > For those who don't know both, they don't care.
>
> "i18n" is a more widely known and widely used word.
>
> Familiar words make people feel more comfortable.
>
> > > 2. In multi-module projects built with Apache Maven, one widely used
> > > naming convention is to name artifacts produced by the nested modules
> > > as <parentId>-<foo>.
> > >
> > > E.g., a discussion:
> > >
> https://stackoverflow.com/questions/9435460/maven-naming-conventions-for-hierarchical-multiple-module-projects
> > >
> > > I mean that the current artifact names of "tomcat-i18n-<locale>" can
> > > be interpreted as module "<locale>" in a parent project "tomcat-i18n".
> > > It means that those artifacts are part of internationalization effort
> > > in Tomcat.
> >
> > I don't see how this is related?! Nor did I bring up to do any migration
> > to Maven or its naming scheme.
>
> I mean that "tomcat-i18n" is the base name.
>
> It is not "tomcat" + "-i18n-de",  but "tomcat-i18n" + "-de", as an example.
>
> The current names are not wrong.
>
>
> > > 3. Overall, my vote for this proposal is -0.5.
> > >
> > > It is not a veto, but I do not like it.
> >
> > So you generally do not object, but don't see a need for?
>
> I really object.
> I just do not veto, I do not end the discussion here at once.
>
>
> If there were other reasons to justify the change (e.g. some
> reorganization of packaging), ...
>
> (E.g. all translation files could be packaged into a single jar.)
>
> > I see no downsides ...
>
> To make it clear, the following are externally visible consequences of
> such a change:
>
> 1. Renaming of artifacts in Maven
> 2. Renaming of libraries in ${catalina.base}/lib
> 3. Change of configuration in conf/catalina.properties file (the
> libraries are mentioned in a jarsToSkip pattern).
>
> The following are internal changes:
> 4. Changes in build procedure (in build.xml, res/maven/mvn-pub.xml).
> 5. Changes in documentation (class-loader-howto.xml mentions the files).
>
> ##1-3 are the downsides that downstream consumers of Tomcat would have
> to adapt to.
>
> I certainly would have to change some of my scripts that I use with
> Tomcat and some configuration settings.
>
> ##4-5 are our internal matter.
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

Re: [PROPOSAL] Tomcat 10: rename language bundles

[Konstantin Kolinko <kn...@gmail.com>]

сб, 1 февр. 2020 г. в 16:31, Michael Osipov <mi...@apache.org>:
>
> Am 2020-01-30 um 18:41 schrieb Konstantin Kolinko:
> > ср, 29 янв. 2020 г. в 00:08, Michael Osipov <mi...@apache.org>:
> >
> > [...]
> >
> > (Being too strict about language is a barrier that may reject people.)
>
> For those who don't know both, they don't care. For those who know care
> to make it right/consistent. I see no downsides to make it right.
>
> This has nothing to do with American, British, You Name It English. It
> is simply about consistent naming.

I see no positive sides in the proposed renaming,
and I do not feel it to be a right thing.

Some downsides were already mentioned by others. I will write down a
more complete list below.

> For those who don't know both, they don't care.

"i18n" is a more widely known and widely used word.

Familiar words make people feel more comfortable.

> > 2. In multi-module projects built with Apache Maven, one widely used
> > naming convention is to name artifacts produced by the nested modules
> > as <parentId>-<foo>.
> >
> > E.g., a discussion:
> > https://stackoverflow.com/questions/9435460/maven-naming-conventions-for-hierarchical-multiple-module-projects
> >
> > I mean that the current artifact names of "tomcat-i18n-<locale>" can
> > be interpreted as module "<locale>" in a parent project "tomcat-i18n".
> > It means that those artifacts are part of internationalization effort
> > in Tomcat.
>
> I don't see how this is related?! Nor did I bring up to do any migration
> to Maven or its naming scheme.

I mean that "tomcat-i18n" is the base name.

It is not "tomcat" + "-i18n-de",  but "tomcat-i18n" + "-de", as an example.

The current names are not wrong.


> > 3. Overall, my vote for this proposal is -0.5.
> >
> > It is not a veto, but I do not like it.
>
> So you generally do not object, but don't see a need for?

I really object.
I just do not veto, I do not end the discussion here at once.


If there were other reasons to justify the change (e.g. some
reorganization of packaging), ...

(E.g. all translation files could be packaged into a single jar.)

> I see no downsides ...

To make it clear, the following are externally visible consequences of
such a change:

1. Renaming of artifacts in Maven
2. Renaming of libraries in ${catalina.base}/lib
3. Change of configuration in conf/catalina.properties file (the
libraries are mentioned in a jarsToSkip pattern).

The following are internal changes:
4. Changes in build procedure (in build.xml, res/maven/mvn-pub.xml).
5. Changes in documentation (class-loader-howto.xml mentions the files).

##1-3 are the downsides that downstream consumers of Tomcat would have
to adapt to.

I certainly would have to change some of my scripts that I use with
Tomcat and some configuration settings.

##4-5 are our internal matter.

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: [PROPOSAL] Tomcat 10: rename language bundles

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Michael,

On 2/1/20 8:31 AM, Michael Osipov wrote:
> Am 2020-01-30 um 18:41 schrieb Konstantin Kolinko:
>> ср, 29 янв. 2020 г. в 00:08, Michael Osipov
>> <mi...@apache.org>:
>>> 
>>> Folks,
>>> 
>>> I recently worked on some localization issues and noticed that,
>>> in my opinion, these JARs are incorrectly named:
>>> 
>>>> tomcat-i18n-cs.jar tomcat-i18n-de.jar tomcat-i18n-es.jar 
>>>> tomcat-i18n-fr.jar tomcat-i18n-ja.jar tomcat-i18n-ko.jar 
>>>> tomcat-i18n-pt-BR.jar tomcat-i18n-ru.jar 
>>>> tomcat-i18n-zh-CN.jar
>>> 
>>> Most people confuse I18N with L10N -- but they are distinct.
>>> According to Mozilla [1] Tomcat is internationalized and
>>> provides localization with those bundles. As far as I
>>> understand that, they should be
>>> 
>>> either tomcat-l10n-<locale>.jar or tomcat-nls-<locale>.jar
>>> 
>>> [...]
>>> 
>>> Comments?
>> 
>> 1. Overall, I am not convinced.
>> 
>> I think that for an average foreigner a discussion about what
>> term is better makes little sense. I know people for whom those
>> words are hard to pronounce and are a little obscure.
>> 
>> Does changing one "obscure" word with another makes life easier?
>> How? Does it help to reach some wider audience?
>> 
>> I think that it would be better to keep it simple (KISS) and
>> continue using the existing historic naming pattern.
>> 
>> I am really proud of 20+ years of history of our project. If
>> there are some things there that are not proper [American]
>> English, it just means that there are different people involved
>> with the project, and it is a good sign.
>> 
>> (Being too strict about language is a barrier that may reject
>> people.)
> 
> For those who don't know both, they don't care. For those who know
> care to make it right/consistent. I see no downsides to make it
> right.
> 
> This has nothing to do with American, British, You Name It English.
> It is simply about consistent naming.
> 
>> 2. In multi-module projects built with Apache Maven, one widely
>> used naming convention is to name artifacts produced by the
>> nested modules as <parentId>-<foo>.
>> 
>> E.g., a discussion: 
>> https://stackoverflow.com/questions/9435460/maven-naming-conventions-
for-hierarchical-multiple-module-projects
>>
>>
>>
>> 
I mean that the current artifact names of "tomcat-i18n-<locale>" can
>> be interpreted as module "<locale>" in a parent project
>> "tomcat-i18n". It means that those artifacts are part of
>> internationalization effort in Tomcat.
> 
> I don't see how this is related?! Nor did I bring up to do any
> migration to Maven or its naming scheme.

Tomcat produces Maven artifacts, even if we don't use a Maven-based
build. I think Konstantin is talking about the artifact names. Mark
also brought this up previously. If we change them, we need to offer
an obvious "upgrade" path. AIUI, these days, Maven doesn't do
latest-dependency resolution but instead requires specific versions to
be referenced. I think that frees us from introducing an incompatible
name-change because every version itself is practically-incompatible
with all previous versions from a dependency-resolution standpoint.
I'd appreciate some clarity from those who understand Maven better than
I.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl41uzIACgkQHPApP6U8
pFiJWw//YmQwkUTfT6ucVVATHBw44ZgDPE1Bo6uC4QlACEA8IVI1F1D91epBbknR
xdK5sXy4zdFe0bmuaD7rf+VA1MsIx6NdNFBgGl/vNnDXVm7SpG3dRfThPDD2+HHa
MZTIB1OfNSuIdh6LZJmg+0cxf2UjtHqCwDeGkPEhVds0pVpkXwtVAVsZtGjyUuCb
F+C8Vd/cW84Ji0CcUErMYgW1+BPC1OB3yd6yvpwJJ5aukQCZ3hZxpahyJRszYHV6
GaN5vfmQAualHHGCULVVcLkY2tS4FTyfRc3p33qQiRbZTA+vebCSfLIUJNhGeHl0
mGkRRykgL+lrnlXow6XlRaHJHl2y4gDKHlI9wq+rCAi9OYWF/IpPWlo4iZZj2k+h
o7c2+7XIs9VdouVbr4rOhGXfXOEsoAflUl5l3XhxO7/T4FBYjy8Ci4PYge5n22vY
u+PytCvVPh4Rs42m3no8aJPu0P8mUmRwdXsG2FyPIjJktvaiQGnIyMaFxqrvNiq6
4MyxGFoPE+xaFHWvo8cjsoWcduMTcuuuo8dxBTeL57c7i+T0TFWUWWDlMarnWWyh
zx5NlczsAObXf+uo0rQ7pJQP3/6NaLdLs+A8mcnOO+L3pF6MNLeQCS2vIgYj2t4p
5VD7gjJ9/E8kmdslXeaQUVP1cp4IcLpiMBkRAzV7WD4XeUmxxuk=
=NQzC
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org