Redmine - Feature #3068
Generic task management (not issues)
2009-03-28 19:46 - Matthew Dixon

ステータス:

New

開始日:

優先度:

Normal

期日:

担当者:
カテゴリ:

Translations

2009-03-28

進捗率:0%

予定工数:

0.00時間対象バージョン:Resolution:
説明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 bypeople other than developers!
Although there are plenty of RoR task management applications (e.g. Tracks) none of them is a fully featured project manager likethis (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 havesomething on RoR.
Regards,Matthew(Updated as suggested by Szabolcs Szász)
関連するチケット:
関連している Redmine - Feature #2082: Rename Issue as Ticket (o...

New

2008-10-24

関連している Redmine - Feature #4636: System-wide Object Label ...

New

2010-01-22

次のチケットが重複 Redmine - Feature #4568: Replace "Issue" for "T...

Closed2010-01-13

次のチケットが重複 Redmine - Feature #4908: Change Issue for Task

Closed2010-02-23

次のチケットが重複 Redmine - Feature #25561: Issues are not tasks:...

Reopened

履歴#1 - 2009-03-29 14:08 - Matthew Dixon- ファイル en-tasks.yml を追加
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 canaccess it.
All the best,Matt

2024-10-12

1/5

#2 - 2013-04-09 13:20 - Dipan Mehta
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 tomess with the 'packaged' software.
It might be more desirable to have Application setting such as 'Label used for Issue'.
#3 - 2013-04-09 15:43 - Dipan Mehta
Add related (duplicate) #4568, #4908#4 - 2013-04-09 16:16 - Daniel Felix- カテゴリ を Translations にセット
Added relation to #4568 (which duplicates this) and #4908 (also a duplicate).
#5 - 2013-04-10 06:00 - Toshi MARUYAMA
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#6 - 2014-05-14 11:03 - Szabolcs Szasz
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 toworkaround 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!
#7 - 2014-05-14 11:53 - Toshi MARUYAMA
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.
#8 - 2014-05-14 14:44 - Szabolcs Szasz
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."2024-10-12

2/5

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.
#9 - 2014-05-14 15:05 - Toshi MARUYAMA
Please post full description to replace for cut and paste.
#10 - 2014-05-14 15:12 - Szabolcs Szasz
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 adifferent 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 completeby allowing proper names to reflect those narrowed-down (customized) "issue" concepts better for the participants of that target problem domain.
#11 - 2014-05-14 15:19 - Szabolcs Szasz(Deleted by note-13 request)#12 - 2014-05-14 15:19 - Szabolcs Szasz
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 thandevelopers!
Although there are plenty of RoR task management applications (e.g. Tracks) none of them is a fully featured project manager like this (withfeatures 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)#13 - 2014-05-14 15:24 - Szabolcs Szasz(Please delete update 11! I thought I was editing it but accidentally posted a new one, sorry!)#14 - 2014-06-13 09:01 - Toshi MARUYAMA

2024-10-12

3/5

Szabolcs Szasz wrote:(Please delete update 11! I thought I was editing it but accidentally posted a new one, sorry!)Done.
#15 - 2014-06-13 09:04 - Toshi MARUYAMA- 説明 を更新
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 oftrackers), 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 (withfeatures 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#16 - 2017-04-10 09:29 - Toshi MARUYAMA- 次のチケットが重複 Feature #25561: Issues are not tasks: please split them を追加#17 - 2017-04-10 09:32 - cyril Thibout
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 theinternal staff.
This issues / task confusion is the source of most rebukes from our customers.
thanks a lot
cyril#18 - 2020-08-21 09:23 - Aleksandar Pavic+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 meaningthat 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

Or:
sed -i "s/\<issue\>/task/g" en.yml

2024-10-12

4/5

sed -i "s/\<Issue\>/Task/g" en.yml#19 - 2022-03-28 22:46 - Aleksandar Pavic
Any news on this? Voting maybe?

ファイル
en-tasks.yml

2024-10-12

27.4 KB

2009-03-29

Matthew Dixon

5/5