[request-tracker-maintainers] [RFR] templates://request-tracker3.6/templates

[Niko Tyni]

Hi debian-l10n-english,

please review the attached debconf templates of request-tracker3.6
3.6.6-2~experimental3, currently in NEW and targeted at experimental
for now.

I'm not quite sure yet if I'll try to push this for Lenny, but the review
and translation round should be useful post-Lenny in any case.

A related question: three other binary packages from the same source
(rt3.6-db-{mysql,postgresql,sqlite}) also contain debconf templates for
one internal variable that is never shown to the user. These are currently
not using po-debconf at all, and the description in the template is
'for internal use only'. Is this a good way to handle them, or should
I use po-debconf for these too and mark them as non-translatable?

The current templates can also be found in the pkg-request-tracker Alioth
SVN repository:

 http://svn.debian.org/wsvn/pkg-request-tracker/packages/request-tracker3.6/branches/experimental

(I'd also appreciate it if somebody would take over the 'reviewer' role
 here as described in <http://wiki.debian.org/I18n/SmithDebconfReviewProcess>,
 but I'll handle that myself if nobody steps up.)

Thanks for your work,
-- 
Niko Tyni   ntyni at debian.org
-------------- next part --------------
Template: request-tracker3.6/rtname
Type: string
_Description: Name for this RT instance:
 Every installation of Request Tracker must have a unique name. RT will
 look for the name in mail messages to figure out what ticket a new piece
 of mail belongs to, and add it to the subject lines of all outgoing
 emails.
 .
 Your domain name or an abbreviation of the name of your organization are
 usually good candidates.
 .
 Please note that once you start using a name, you should probably never
 change it. Otherwise, mail for existing tickets won't get put in the right
 place.
 .
 This setting corresponds to the $rtname variable in RT_SiteConfig.pm .

Template: request-tracker3.6/organization
Type: string
_Description: Identifier for this RT instance:
 In addition to its name, every installation of Request Tracker must also have
 a unique identifier. It is used to generate Message-Id headers of outgoing
 emails and unique ticket identifiers when linking between RT
 installations.
 .
 Using your fully qualified host or domain name is recommended.
 .
 This setting corresponds to the $Organization variable in RT_SiteConfig.pm
 .

Template: request-tracker3.6/correspondaddress
Type: string
_Description: Default email address for RT correspondence:
 This address will be listed in From: and Reply-To: headers of
 correspondence email tracked by RT, unless overridden by a queue-specific
 address.
 .
 This setting corresponds to the $CorrespondAddress variable in
 RT_SiteConfig.pm .

Template: request-tracker3.6/commentaddress
Type: string
_Description: Default email address for RT comments:
 This address will be listed in From: and Reply-To: headers of comment
 email, unless overridden by a queue-specific address. (Comments can be
 used for adding ticket information that is not visible to the client.)
 .
 This setting corresponds to the $CommentAddress variable in
 RT_SiteConfig.pm .

Template: request-tracker3.6/webbaseurl
Type: string
_Description: Base URL to the web interface:
 Please specify the scheme, server and (optionally) port for constructing
 URLs to the RT web interface.
 .
 The value should not have a trailing slash (/).
 .
 This setting corresponds to the $WebBaseURL variable in RT_SiteConfig.pm .

Template: request-tracker3.6/webpath
Type: string
_Description: path to the RT web interface:
 If the RT web interface is going to be installed somewhere other than at
 the root of your server, you should specify the path to it here.
 .
 The value requires a leading slash (/) but not a trailing one.
 .
 This setting corresponds to the $WebPath variable in RT_SiteConfig.pm .

Template: request-tracker3.6/handle-siteconfig-permissions
Type: boolean
_Description: Handle RT_SiteConfig.pm permissions?
 The main RT configuration file, /etc/request-tracker3.6/RT_SiteConfig.pm,
 contains the database password and should therefore not be world-readable.
 On the other hand, the database password must be known by the web interface,
 usually running as the www-data user. 
 .
 The normal setup is to make the file owned by root with the group
 www-data, and set the mode to 0640 (readable by the group but not
 the world.) This can be made automatically, but please consider the
 security implications first. For instance, if you have php installed 
 on the system, anyone running a php script could read the database 
 access details if the file is readable by www-data.
 .
 If the answer is negative, the file will be readable only by root,
 and you will have to set up the access control yourself.
 .
 Note: if you are using SQLite as the database backend, your answer
 will also affect the permissions of automatically generated local 
 database files.

Template: request-tracker3.6/fix-initialdata-442398
Type: boolean
_Description: Fix the "10 highest priority tickets I own" table automatically?
 RT version 3.6.1 (the one distributed with the Etch release) had a bug
 in the database initialization data that broke links in the "10 highest
 priority tickets I own" table in certain circumstances.
 .
 While the initialization data has been fixed after Etch, existing
 databases created with the Etch version can only be fixed by changing
 the database contents. This can be done automatically if you want.
 Note that if the database is already OK, this won't change anything.
 .
 The change will be attempted only once. If fixing the database fails for 
 some reason (for example because the database is unavailable), it won't be
 tried again unless this setting is re-enabled with eg. dpkg-reconfigure.
 .
 See Debian bug #442398, http://bugs.debian.org/442398 , for more 
 information.