Bug#708660: [Openstack-devel] Bug#708660: [LCFC] templates://keystone/{keystone.templates}
Quoting Thomas Goirand (z...@debian.org):
> Thanks for pointing to the right documentation Justin. I really didn't
> expect you would teach me something about OpenStack! :)
>
> So indeed, we probably should write "(previously known as project)" or
> something similar.
Doh, I'm lost again.
Attached last version of templates...
# These templates have been reviewed by the debian-l10n-english
# team
#
# If modifications/additions/rewording are needed, please ask
# debian-l10n-engl...@lists.debian.org for advice.
#
# Even minor modifications require translation updates and such
# changes should be coordinated with translators and reviewers.
Template: keystone/configure_db
Type: boolean
Default: false
_Description: Set up a database for Keystone?
No database has been set up for Keystone to use. Before
continuing, you should make sure you have the following information:
.
* the type of database that you want to use;
* the database server host name (that server must allow TCP connections from
this
machine);
* a username and password to access the database.
.
If some of these requirements are missing, do not choose this option and run
with
regular SQLite support.
.
You can change this setting later on by running "dpkg-reconfigure -plow
keystone".
Template: keystone/auth-token
Type: password
_Description: Authentication server administration token:
Please enter the token to use with the authentication
server.
Template: keystone/create-admin-tenant
Type: boolean
Default: false
# Translators: a "tenant" in OpenStack world is
# an entity that contains one or more username/password couples.
# It's typically the tenant that will be used for billing. Having more than one
# username/password is very helpful in larger organization.
# You're advised to either keep "tenant" without translating it
# or keep it parenthezised. Example for French:
# locataire ("tenant")
_Description: Register administration tenants?
For OpenStack to work, you need a basic tenant configuration. The
creation of these administration tenants can be done automatically.
Template: keystone/admin-user
Type: string
Default: admin
_Description: Username of the administrative user:
Please enter a username for the administrative user.
Template: keystone/admin-email
Type: string
Default: root@localhost
_Description: Email address of the administrative user:
Please enter the email address of the administrative user.
Template: keystone/admin-password
Type: password
_Description: Password of the administrative user:
Please enter a password for the administrative user.
Template: keystone/admin-password-confirm
Type: password
_Description: Re-enter password to verify:
Please enter the same administrative password again to verify that you have
typed it
correctly.
Template: keystone/passwords-do-not-match
Type: error
_Description: Password input error
The two passwords you entered were not the same. Please try again.
Template: keystone/admin-role-name
Type: string
Default: admin
_Description: Name of the administrative role:
Please enter the name of the administrative role.
Template: keystone/admin-tenant-name
Type: string
Default: admin
# Translators: a "tenant" in OpenStack world is
# an entity that contains one or more username/password couples.
# It's typically the tenant that will be used for billing. Having more than one
# username/password is very helpful in larger organization.
# You're advised to either keep "tenant" without translating it
# or keep it parenthezised. Example for French:
# locataire ("tenant")
_Description: Name of the administrative tenant:
Please enter the name of the administrative tenant.
Template: keystone/register-endpoint
Type: boolean
Default: false
_Description: Register Keystone endpoint?
Each OpenStack service (each API) should be registered in order to be
accessible. This is done using "keystone service-create" and "keystone
endpoint-create". This can be done automatically now.
Template: keystone/endpoint-ip
Type: string
_Description: Keystone endpoint IP address:
Please enter the IP address that will be used to contact Keystone.
Template: keystone/region-name
Type: string
Default: regionOne
_Description: Name of the region to register:
OpenStack supports using availability zones, with each region representing
a location. Please enter the zone that you wish to use when registering the
endpoint.
signature.asc
Description: Digital signature
Bug#708660: [LCFC] templates://keystone/{keystone.templates}
Quoting Justin B Rye (justin.byam@gmail.com):
> "Propriétaire" ("Landlord, owner") might make sense, but the actual
> word is "tenant", which equates to "locataire". I suspect this is one
> that's best treated as a meaningless name...
/me baffled, as Thomas was: you're now teaching us French and you're
bloody right..:-)
signature.asc
Description: Digital signature
Bug#708660: [LCFC] templates://keystone/{keystone.templates}
Christian PERRIER wrote:
> I'm thinking about translators who need information in order to choose
> the right thing to do.
>
> I propose the following:
>
>
> Template: keystone/create-admin-tenant
> Type: boolean
> Default: false
> # Translators: a "tenant" in OpenStack world is
> # an entity that contains one or more username/password couples.
> # It's typically the tenant that will be used for billing. Having more than
> one
> # username/password is very helpful in larger organization.
^s
> # You're advised to either keep "tenant" without translating it
> # or keep it aside with your translation. Example for French:
(By "keep it aside" do you mean "keep it set off by commas"?)
> # propriétaire ("tenant")
"Propriétaire" ("Landlord, owner") might make sense, but the actual
word is "tenant", which equates to "locataire". I suspect this is one
that's best treated as a meaningless name...
> _Description: Register administration tenants?
> For OpenStack to work, you need a basic tenant configuration. The
> creation of these administration tenants can be done automatically.
(In fact I had forgotten that for keystone we were talking plural
tenants.)
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708660: [LCFC] templates://keystone/{keystone.templates}
Justin B Rye wrote: > (By "keep it aside" do you mean "keep it set off by commas"?) I mean "set off by parentheses", obviously. Or just "parenthesized". -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708660: [Openstack-devel] Bug#708660: [LCFC] templates://keystone/{keystone.templates}
On 06/15/2013 05:25 AM, Justin B Rye wrote: > Thomas Goirand wrote: >> In OpenStack, a tenant is a synonym of a project. I don't think it was a >> rename, I saw both. For example, the OpenStack dashboard (Horizon) shows >> "projects" and not "tenants" in the admin interface: >> http://www.openstack.org/themes/openstack/images/essex/project-users.jpg >> >> Or this one too: >> http://docs.openstack.org/trunk/openstack-compute/admin/content/figures/1/figures/horizon-screenshot.jpg >> >> I'm cc-ing the OpenStack list just in case I'm wrong. :) > > I was going by phrases like: > > # Note: Earlier versions of OpenStack used the term "project" instead > # of "tenant". Because of this legacy terminology, some command-line > # tools use --project_id when a tenant ID is expected. > > (http://docs.openstack.org/trunk/openstack-compute/admin/content/users-and-projects.html) > > but if it isn't obviously a good idea then we should probably avoid > complicating things with alternative names. > > (I'm a bit baffled by this choice of term, though. Why would a > "resource container" occupied by users, keys, etc. be called a > "tenant"? It seems backwards; wouldn't it make more sense if the > individual resources doing the occupying were thought of as "tenants" > and the container was called a "leasehold" or "domicile" or whatever? > I hope the person who coined the term wasn't confusing "tenants" with > "tenements" or "tenure" or something...) Thanks for pointing to the right documentation Justin. I really didn't expect you would teach me something about OpenStack! :) So indeed, we probably should write "(previously known as project)" or something similar. Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708660: [LCFC] templates://keystone/{keystone.templates}
Quoting Thomas Goirand (z...@debian.org):
> I think that someone who doesn't know what a tenant is in OpenStack
> should either give-up using it or read some more documentation. So I'd
> be fine with simply removing "(project)".
Still...:-)
I'm thinking about translators who need information in order to choose
the right thing to do.
I propose the following:
Template: keystone/create-admin-tenant
Type: boolean
Default: false
# Translators: a "tenant" in OpenStack world is
# an entity that contains one or more username/password couples.
# It's typically the tenant that will be used for billing. Having more than one
# username/password is very helpful in larger organization.
# You're advised to either keep "tenant" without translating it
# or keep it aside with your translation. Example for French:
# propriétaire ("tenant")
_Description: Register administration tenants?
For OpenStack to work, you need a basic tenant configuration. The
creation of these administration tenants can be done automatically.
signature.asc
Description: Digital signature
Bug#708660: [LCFC] templates://keystone/{keystone.templates}
Thomas Goirand wrote: > In OpenStack, a tenant is a synonym of a project. I don't think it was a > rename, I saw both. For example, the OpenStack dashboard (Horizon) shows > "projects" and not "tenants" in the admin interface: > http://www.openstack.org/themes/openstack/images/essex/project-users.jpg > > Or this one too: > http://docs.openstack.org/trunk/openstack-compute/admin/content/figures/1/figures/horizon-screenshot.jpg > > I'm cc-ing the OpenStack list just in case I'm wrong. :) I was going by phrases like: # Note: Earlier versions of OpenStack used the term "project" instead # of "tenant". Because of this legacy terminology, some command-line # tools use --project_id when a tenant ID is expected. (http://docs.openstack.org/trunk/openstack-compute/admin/content/users-and-projects.html) but if it isn't obviously a good idea then we should probably avoid complicating things with alternative names. (I'm a bit baffled by this choice of term, though. Why would a "resource container" occupied by users, keys, etc. be called a "tenant"? It seems backwards; wouldn't it make more sense if the individual resources doing the occupying were thought of as "tenants" and the container was called a "leasehold" or "domicile" or whatever? I hope the person who coined the term wasn't confusing "tenants" with "tenements" or "tenure" or something...) -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708660: [LCFC] templates://keystone/{keystone.templates}
On 06/14/2013 02:01 PM, Christian PERRIER wrote: > Quoting Justin B Rye (justin.byam@gmail.com): > >>> Template: keystone/admin-tenant-name >> [...] >>> Please enter the name of the administrative tenant (project). >> >> The bit in parentheses is explaining the word "tenant" by offering the >> equivalent jargon used in a previous system. This makes me wonder >> whether perhaps we should say something like: >> >> Please enter the name of the administrative "tenant" (formerly known >> as a "project"). >> >> But I haven't actually put that in my revised patch. Meanwhile I've >> noticed that Quantum has similar templates phrased differently... > > Would be interesting to have Thomas' input about this. Thomas? > (CC'ed explicitly just in case) I think that someone who doesn't know what a tenant is in OpenStack should either give-up using it or read some more documentation. So I'd be fine with simply removing "(project)". Just a bit of background here. In OpenStack, a "tenant" is an entity that contains one or more username/password couples. It's typically the tenant that will be used for billing. Having more than one username/password is very helpful in larger organization. In OpenStack, a tenant is a synonym of a project. I don't think it was a rename, I saw both. For example, the OpenStack dashboard (Horizon) shows "projects" and not "tenants" in the admin interface: http://www.openstack.org/themes/openstack/images/essex/project-users.jpg Or this one too: http://docs.openstack.org/trunk/openstack-compute/admin/content/figures/1/figures/horizon-screenshot.jpg I'm cc-ing the OpenStack list just in case I'm wrong. :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708660: [LCFC] templates://keystone/{keystone.templates}
Quoting Justin B Rye (justin.byam@gmail.com): > > Template: keystone/admin-tenant-name > [...] > > Please enter the name of the administrative tenant (project). > > The bit in parentheses is explaining the word "tenant" by offering the > equivalent jargon used in a previous system. This makes me wonder > whether perhaps we should say something like: > > Please enter the name of the administrative "tenant" (formerly known > as a "project"). > > But I haven't actually put that in my revised patch. Meanwhile I've > noticed that Quantum has similar templates phrased differently... Would be interesting to have Thomas' input about this. Thomas? (CC'ed explicitly just in case) signature.asc Description: Digital signature
Bug#708660: [LCFC] templates://keystone/{keystone.templates}
Christian PERRIER wrote: > This is the last call for comments for the review of debconf > templates for keystone. [...] > Template: keystone/admin-user > Type: string > Default: admin > _Description: User name of the administrative user: > Please enter a username for the administrative user. For consistency, s/User name/username/ Also, I've finally found out what this one means: > Template: keystone/admin-tenant-name [...] > Please enter the name of the administrative tenant (project). The bit in parentheses is explaining the word "tenant" by offering the equivalent jargon used in a previous system. This makes me wonder whether perhaps we should say something like: Please enter the name of the administrative "tenant" (formerly known as a "project"). But I haven't actually put that in my revised patch. Meanwhile I've noticed that Quantum has similar templates phrased differently... -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package diff -ru keystone-2013.1.1.pristine/debian/keystone.templates keystone-2013.1.1/debian/keystone.templates --- keystone-2013.1.1.pristine/debian/keystone.templates2013-05-16 07:52:48.0 +0100 +++ keystone-2013.1.1/debian/keystone.templates 2013-06-13 20:14:19.568168023 +0100 @@ -11,20 +11,19 @@ Type: boolean Default: false _Description: Set up a database for Keystone? - No database has been set up for Keystone to use. If you want - to set one up now, please make sure you have all needed - information: + No database has been set up for Keystone to use. Before + continuing, you should make sure you have the following information: . - * the host name of the database server (which must allow TCP -connections from this machine); - * a username and password to access the database; - * the type of database management software you want to use. + * the type of database that you want to use; + * the database server host name (that server must allow TCP connections from this +machine); + * a username and password to access the database. . - If you don't choose this option, no database will be set up and - Keystone will use regular SQLite support. + If some of these requirements are missing, do not choose this option and run with + regular SQLite support. . - You can change this setting later on by running "dpkg-reconfigure - -plow keystone". + You can change this setting later on by running "dpkg-reconfigure -plow + keystone". Template: keystone/auth-token Type: password @@ -35,66 +34,67 @@ Template: keystone/create-admin-tenant Type: boolean Default: false -_Description: Register admin tenants? - For Openstack to work, you need a basic tenant configuration. The keystone - package can create these admin tenants automatically for you. +_Description: Register administration tenants? + For OpenStack to work, you need a basic tenant configuration. The + creation of these administration tenants can be done automatically. Template: keystone/admin-user Type: string Default: admin -_Description: User name of the admin user: - Please enter an user name for the administrative user. +_Description: Username of the administrative user: + Please enter a username for the administrative user. Template: keystone/admin-email Type: string Default: root@localhost -_Description: Email address of the admin user: +_Description: Email address of the administrative user: Please enter the email address of the administrative user. Template: keystone/admin-password Type: password -_Description: Password of the admin user: +_Description: Password of the administrative user: Please enter a password for the administrative user. Template: keystone/admin-password-confirm Type: password -_Description: Password of the admin user (confirm): - Please confirm the password for the administrative user. +_Description: Re-enter password to verify: + Please enter the same administrative password again to verify that you have typed it + correctly. Template: keystone/passwords-do-not-match Type: error -Description: Password mismatch - The password and its confirmation do not match. +_Description: Password input error + The two passwords you entered were not the same. Please try again. Template: keystone/admin-role-name Type: string Default: admin -_Description: Name of the admin role: +_Description: Name of the administrative role: Please enter the name of the administrative role. Template: keystone/admin-tenant-name Type: string Default: admin -_Description: Name of the admin tenant: +_Description: Name of the administrative tenant: Please enter the name of the administrative tenant (project). Template: keystone/register-endpoint Type: boolean Default: false -_Description: Register keystone endpoint? - Each Openstack services (each API) should be registered in order to be +_Description: Register Keystone endpoint? + Each OpenStack service
Bug#708660: [LCFC] templates://keystone/{keystone.templates}
This is the last call for comments for the review of debconf
templates for keystone.
The reviewed templates will be sent on Saturday, June 15, 2013 to this bug
report
and a mail will be sent to this list with "[BTS]" as a subject tag.
--
# These templates have been reviewed by the debian-l10n-english
# team
#
# If modifications/additions/rewording are needed, please ask
# debian-l10n-engl...@lists.debian.org for advice.
#
# Even minor modifications require translation updates and such
# changes should be coordinated with translators and reviewers.
Template: keystone/configure_db
Type: boolean
Default: false
_Description: Set up a database for Keystone?
No database has been set up for Keystone to use. Before
continuing, you should make sure you have the following information:
.
* the type of database that you want to use;
* the database server host name (that server must allow TCP connections from
this
machine);
* a username and password to access the database.
.
If some of these requirements are missing, do not choose this option and run
with
regular SQLite support.
.
You can change this setting later on by running "dpkg-reconfigure -plow
keystone".
Template: keystone/auth-token
Type: password
_Description: Authentication server administration token:
Please enter the token to use with the authentication
server.
Template: keystone/create-admin-tenant
Type: boolean
Default: false
_Description: Register administration tenants?
For OpenStack to work, you need a basic tenant configuration. The
creation of these administration tenants can be done automatically.
Template: keystone/admin-user
Type: string
Default: admin
_Description: User name of the administrative user:
Please enter a username for the administrative user.
Template: keystone/admin-email
Type: string
Default: root@localhost
_Description: Email address of the administrative user:
Please enter the email address of the administrative user.
Template: keystone/admin-password
Type: password
_Description: Password of the administrative user:
Please enter a password for the administrative user.
Template: keystone/admin-password-confirm
Type: password
_Description: Re-enter password to verify:
Please enter the same administrative password again to verify that you have
typed it
correctly.
Template: keystone/passwords-do-not-match
Type: error
_Description: Password input error
The two passwords you entered were not the same. Please try again.
Template: keystone/admin-role-name
Type: string
Default: admin
_Description: Name of the administrative role:
Please enter the name of the administrative role.
Template: keystone/admin-tenant-name
Type: string
Default: admin
_Description: Name of the administrative tenant:
Please enter the name of the administrative tenant (project).
Template: keystone/register-endpoint
Type: boolean
Default: false
_Description: Register Keystone endpoint?
Each OpenStack service (each API) should be registered in order to be
accessible. This is done using "keystone service-create" and "keystone
endpoint-create". This can be done automatically now.
Template: keystone/endpoint-ip
Type: string
_Description: Keystone endpoint IP address:
Please enter the IP address that will be used to contact Keystone.
Template: keystone/region-name
Type: string
Default: regionOne
_Description: Name of the region to register:
OpenStack supports using availability zones, with each region representing
a location. Please enter the zone that you wish to use when registering the
endpoint.
Source: keystone
Section: net
Priority: extra
Maintainer: PKG OpenStack
Uploaders: Loic Dachary (OuoU) ,
Julien Danjou ,
Thomas Goirand ,
Ghe Rivero ,
Mehdi Abaakouk
Build-Depends: debhelper (>= 9),
python-all (>= 2.6.6-3~),
po-debconf,
git,
openstack-pkg-tools (>= 4)
Build-Depends-Indep: pep8 (>= 1.3.3),
pylint,
python-all-dev (>= 2.6.6-3~) | python-support,
python-babel,
python-coverage,
python-dateutil,
python-eventlet,
python-greenlet,
python-httplib2,
python-iso8601,
python-keyring,
python-keystoneclient (>= 1:0.2),
python-ldap,
python-lxml,
python-memcache,
python-migrate,
python-mox,
python-netifaces,
python-nose,
python-nosexcover,
python-novaclient,
python-oslo.config,
python-pam,
python-passlib,
python-paste,
python-pastedeploy,
python-prettytable,
python-requests,
python-routes,
python-setuptools,
python-sphinx,
python-sqlalchemy,
python-sqlite,
python-swiftclient (>= 1:1.2.0),
python-unittest2,
python-webob (>= 1.2.3),
python-webtest
Standards-Version: 3.9.3
Homepage: http://keystone.openstack.org/
Vcs-Browser:
http://anonscm.debian.org/gitweb/?p=openstack/keystone.git;a=summary
Vcs-Git: git://anonscm.debian.org/openstack/keystone.git
Package: python-keystone
Architecture: all
Section: python
Pre-Depends: dpkg (>= 1.15.6~)
Depends: ${python:Depends}, ${misc:Depends},
python-dateutil,
python-eventlet,
python-greenlet,
