Hi,

I realised there's a very simple way to do this via the language file. I'm uploading a new English language file which I search and replaced so that it simply calls issues tasks.

Combine that with custom trackers and workflows, and the suggested feature is >90% done.

I'm not really anything on this project (apart from a fussy tester) so if someone thinks it's useful, please feel free to post it where where people can access it.

All the best,

Matt
--------------------------------------------------------------------------------
While this is possible through the locale file changes - it might still be not convenient for some organization where the admins do not prefer you to mess with the 'packaged' software.

It might be more desirable to have Application setting such as 'Label used for Issue'.

--------------------------------------------------------------------------------
Add related (duplicate) #4568, #4908
--------------------------------------------------------------------------------
Added relation to #4568 (which duplicates this) and #4908 (also a duplicate).
--------------------------------------------------------------------------------
Is this issue category Translation?

Japanese: チケット *= ticket*
source:tags/2.3.0/config/locales/ja.yml#L486
Traditional Chinese: 問題 *= problem*
source:tags/2.3.0/config/locales/zh-TW.yml#L575
Simplified Chinese: 问题 *= problem*
source:tags/2.3.0/config/locales/zh.yml#L450
--------------------------------------------------------------------------------
Excellent point!

*NOTE:* the actually used semantic content of the nicely generic term "issue" *_varies by project_*!

Thus, changing it globally on the system-level cannot be a real solution. Also, changing this in the translation layer is even more of a hack to workaround the missing option.

Also:

_Please edit the issue description so as to also request an option for changing *"Tracker", too*!_ That term resonates with even less people than "issue" (not even developers in general). And changing it globally (to e.g. "Issue type") would be equally wrong, as the term "issue" and "tracker" would usually need to be changed together, in tandem.

Thanks, cheers!
--------------------------------------------------------------------------------
Szabolcs Szasz wrote:
> _Please edit the issue description so as to also request an option for changing *"Tracker", too*!_

Please post what should be added.
--------------------------------------------------------------------------------
Toshi MARUYAMA wrote:
> Szabolcs Szasz wrote:
> > _Please edit the issue description so as to also request an option for changing *"Tracker", too*!_
>
> Please post what should be added.

Thanks for watching, Toshi!

The original issue description says (among other things):

_"There could even be a per project toggle setting, whether to call them issues or tasks!"_

1. As (I figure) that is the main point, that should stand on a _separate paragraph_.

2. It should read: _"There should be a per-project setting, what to actually call "issues" in that project."_

3. And, to cover "Trackers", another sentence should be added, right next to it: _"And, as a corollary, add a related option that tells what to call "tracker" in that project."_

4. You might also add: _"If empty, the current names are used by default. Otherwise, throughout the whole UI (including emails sent and documents generated for human reading), they are replaced with the terms given in the project settings. Ideally, corresponding system-wide settings could also be added, a) to optionally enable these project-level settings, and b) to set the defaults for every new project."_

5. Break the rest of the text (from _"By allowing this more generic description..."_) to a new paragraph.

(If you wish, I could also post a new issue, setting this as related -- but that would feel duplicating it, and may risk closing it by others.)

Thanks!
Sz.

--------------------------------------------------------------------------------
Please post full description to replace for cut and paste.
--------------------------------------------------------------------------------
BTW, actually, it's an interesting question, how it relates/interferes with the translation layer.

1. This, in fact, appears to be a _localization_ problem. However, not belonging to a given language (translation) or country locale, but to the "locale" of a _problem domain_.

2. Problem domains exist independently of languages, so this change must also be orthogonal to language translations. It should apply on a different level, being subject to language translations itself.

3. After all, this is actually _subclassing_: subclassing the _generic_ Redmine tool to apply better to a specific problem domain.

4. As the issue (tracker) data models can already be customized ("subclassed") manually to fit a target domain, it is only natural to make it complete by allowing proper names to reflect those narrowed-down (customized) "issue" concepts better for the participants of that target problem domain.

--------------------------------------------------------------------------------
(Deleted by note-13 request)
--------------------------------------------------------------------------------
Toshi MARUYAMA wrote:
> Please post full description to replace for cut and paste.

OK, here it goes (with further slight modifications):

----
I'd like to suggest an addition which would make this excellent app useable in a much broader set of situations.

Issues -> Tasks.

There should be a per-project setting, what to actually call _"issue"_ in that project. And, as a corollary, add a related option that tells what to call _"tracker"_ there, too. (E.g. "task type", if "issue" is renamed to "task".)

If left empty, the generic names are used by default, as before. Otherwise, throughout the whole UI (including emails sent & documents generated for human reading), they are replaced with the terms given in the project settings. Ideally, corresponding system-wide settings could also be added, a) to optionally enable these project-level settings, and b) to set the defaults for every new project.

By allowing these more generic descriptions (and other types of trackers), suddenly the same project logic is understandable by people other than developers!

Although there are plenty of RoR task management applications (e.g. Tracks) none of them is a fully featured project manager like this (with features like file management, gantt charts, wiki etc).

And although there are project management apps on other platforms (e.g. ProjectFork on joomla) it would be great to have something on RoR.

Regards,
Matthew
(Updated as suggested by Szabolcs Szász)
--------------------------------------------------------------------------------
(Please delete update _11_! I thought I was editing it but accidentally posted a new one, sorry!)
--------------------------------------------------------------------------------
Szabolcs Szasz wrote:
> (Please delete update _11_! I thought I was editing it but accidentally posted a new one, sorry!)

Done.
--------------------------------------------------------------------------------
Original description:

-----------------------

I'd like to suggest an addition which would make this excellent app useable in a much broader set of situations.

Issues -> Tasks.

There could even be a per project toggle setting, whether to call them issues or tasks! By allowing this more generic description (and other types of trackers), suddenly the same project logic is understandable by people other than developers!

Although there are plenty of RoR task management applications (e.g. Tracks) none of them is a fully featured project manager like this (with features like file management, gantt charts, wiki etc).

And although there are project management apps on other platforms (e.g. ProjectFork on joomla) it would be great to have something on RoR.

Regards,
Matthew

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
Hi

I don't understand where is the actual status of this issue that has been published 8 years ago.

I'm in favor of renaming the current issues module as tasks module since it is connected to the Gantt which has nothing to do with issues / tickets. Even if we think differently we do need to separate issues that are mainly submitted by the end user , from tasks that are generally submitted by the internal staff.

This issues / task confusion is the source of most rebukes from our customers.

thanks a lot

cyril
--------------------------------------------------------------------------------
+1

For native English speaking users (USA, Canada, and UK),
word issue carries bad meaning, usually connected towards personality problems.

So they immediately have bad attitude towards Redmine.

Preferably Issues should be renamed to tasks which carry meaning
that something should be done.

Thanks!

P.S.

Here is quick sed command to replace it on systems
where sed is available...

Just rename en.new.yml to en.yml after this command)...

@sed -r 's/(^.*)\: Issue/\1\: Task/g' en.yml > en.new.yml
@

--------------------------------------------------------------------------------
Any news on this? Voting maybe?
--------------------------------------------------------------------------------

relates,New,2082,Rename Issue as Ticket (or ...) in GUI
relates,New,4636,System-wide Object Label Settings and the general Open Pario Malaise
duplicates,Closed,4568,Replace "Issue" for "Task"
duplicates,Closed,4908,Change Issue for Task
duplicates,Reopened,25561,Issues are not tasks: please split them