-----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 >> <micha...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
