Redmine

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

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.

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


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


sed -i "s/\<Issue\>/Task/g" en.yml


Any news on this? Voting maybe?