You cannot change name of application to name with diacritics, because these
names are used as project names just as application name. If this can be
done with change config.xml file, there must be two information:
<name> as application name and <project> (for example) with project name
(without dangerous chars)
project could be rather <widget> attribute (just like id and version)
--------------------------------------------------------------------------
Android doesn't support Unicode activity/class names. This is a limitation
of their tools, which we use to generate activities. On Jul 23, 2014 2:32
PM, "Carlos Santana" <csan...@gmail.com> wrote:
I agree maybe adding NAME is a human readable field => NAME is an
application name *that can be modify in config.xml*
On Wed, Jul 23, 2014 at 5:29 PM, Carlos Santana <csan...@gmail.com> wrote:
Michal what platform you tested?
On Wed, Jul 23, 2014 at 5:05 PM, Michal Mocny <mmo...@chromium.org> wrote:
Well, first, I would like to officially agree that people speaking in
language with diacritics are people :)
I'm not 100% sure of your exact proposal, but I think you are suggesting
that: a) "cordova create Foo" should create a project in directory Foo with
name "Foo", and not name "Hello World" and b) Support for unicode for Name?
Regarding (a), I'm a bit torn. It seems like a good change in isolation, but
personally I think we should just get rid of all parameters except Path.
Specifically, you have to edit your config.xml to change a bunch more than
just packageId and Name, so why are those special? Also, "cordova create
Foo" will still create the Hello World application, which should specify its
default name/packageId in its config.xml, why override those at create time?
Regarding (b), I just changed my config.xml to: <name>/daɪ.əˈkrɪtɨk/</name>
or <name>διακριτικός</name> or <name>ąćęłńóśźż</name>.. and it always worked
exactly as expected. Not sure what else we require?
On Wed, Jul 23, 2014 at 4:44 PM, Jan Velecký <vve...@seznam.cz> wrote:
Hello, probably many of you developers are english speaking. But most of
languages have diacritics. Below is CLI create syntax: create <PATH> [ID
[NAME [CONFIG]]] ....... creates a Cordova project in the specified PATH,
with ID reverse-domain-style package name - used in <widget id> NAME is a
human readable field CONFIG is a json string whose key/values will be
included
Look at item NAME – human readable. CLI tell us, that this is human readable
field, I think diacritics is very very human readable, if people speaking in
language with diacritics are people... In fact, this option is name of
project, but name of project cannot be diacritical, because of historical
reasons and their impacts on present software...
Another thing, don't you think, that is the best practise to use same
project directory name as project name?
So, my proposal is change it to (line 1 and 3): create <PATH> [ID [NAME
[CONFIG]]] ....... creates a Cordova project of PATH name in the specified
PATH, with ID reverse-domain-style package name - used in <widget id> NAME
is an application name CONFIG is a json string whose key/values will be
included
1.) Typically, there cannot be two project of same name alike there cannot
be two directories of same name. Also, there are good reasons to use in both
of names only latin letters, numbers, hyphen and underscore. So, why path
name isn't also project name? 2.) With name attribute supporting more chars,
it can be used as application name (showed on device/emulator). So if
developer develops czech application with off course czech name and with
diacritics too, he don't have to editing any files in platforms projects.
Also, if he develops english-named application, but with some rare char to
make name attractive, he don't have to do this. And this should be name of
project in config.xml in project root, so user (in future) can change this
application name and CLI changes names of applciation name in each project
instead of him. 3.) If NAME is omitted, project directory, name of platform
projects and application names should be same.
This have only benefits, and for most of developers I think with no broken
backward-compability.
-- Carlos Santana <csan...@gmail.com>
-- Carlos Santana <csan...@gmail.com>
