Implement translatable module names (with context)

module names *can't* be translated. they have a specific name, in english, and that's how you find them on drupal.org. module names come from the .info file, so the only way to "translate" them would be to edit your .info files (which would only work for a single language, anyway). plus, you're never supposed to put dynamic strings inside t().

I think module names are one of those special cases where you are allowed to pass a dynamic string through t().

I asked about this on the translator's list. Someone replied with:

http://lists.drupal.org/pipermail/translations/2007-June/000388.html

This is a very clear explaination why module names aren't translated on the admin/build/modules page, and therefore, why they shouldn't be translated here in update_status, either.

Hah, and now Gabor replies that they could be:
http://lists.drupal.org/pipermail/translations/2007-June/000390.html

;) Ugh, now I'm not sure what I think...

I'm still leaning towards won't fix, but in fairness, I guess this does need review. ;)

Ok, let's try to make it specific so that we all understand the same thing. In /admin/build/modules we currently see. for example:

Node
User
Taxonomy
......
Pathauto
Taxonomy Access Control Lite
ACL
LoginToboggan
Xstatistics

- No other name (or filename) appears on that page, still the admin must be able to say which module is which.
- At the same time, some of the modules have entries in the admin menu, same as or similar to these names, which currently may be translated (or not). Making these entries here translatable would make some of them appear with that same translation (if it exists).
- It has been suggested by Gabor in the mailing list that the module's original filename could be added.

So, what should the admin see in /admin/build/modules to be able to work?

One of my points on the mailing was that you already need to pair "Taxonomy Access Control Lite" to a path where that module is and a filename (directory name) for the module. The logical groupings on the module page might also coincide with the physical grouping to folders (eg with i18n modules) or might not (eg with various taxonomy related modules). You might have your modules in the drupal modules folder, in sites/all, in one of your sites folders and so on.

My suggestion on the mailing list was:

To help this situation, we can put a 'title="'. t('Original module name: %name, location: %path', array('%name' => $name, '%path' => $path)) . '"' onto the module list items for example (and let the module names be translated).

This is turning into a discussion about the translatability of module names in core, so let's move this issue there. I'm not going to commit hass's patch to 5.x update_status.module, since D5 core doesn't handle this well and I agree with CogRusty that without better support in core for this, it would be too confusing to allow translation of module names. So, let's talk about this in the context of how D6's admin UI should work. Besides, update_status will be part of the D6 admin UI soon enough, so this feature request might as well live in the core issue queue, anyway. ;)

(p.s. Gabor, is this a "language system" feature, since it's about translatability, or is that Component reserved for the specific localization/translation subsystem itself not t() call sites, and this should really be "base system" since it's about the admin/build/modules page?)

language system and locale.module are very close. I would classify broader language stuff, like node languages, node translation, page language detection and so on to the language system, and "strictly" locale related stuff to the locale module. The broader "language system" was introduced as more modules are now involved in languages, system module, node module, the installer all have code for it.

Either way, I monitor an aggregate of the two categories for new issues and comments coming along so it is fine in either category :)

Moving this feature request to 7.x

I am still on the position that module names are translated elsewhere (like menu items in the administration menu), so not translating them here is awkward.

It's perfectly impossible to translate module names until we add a proper context to those (see #334283: Add msgctxt-type context to t()). There are simply too short.

New status ;)

(we're not waiting for more info, we're blocked on another issue)

I do not accept translation of menu items as examples for module name translations..
The menu item title is the explanation of the page it refers to. Like when you click on the 'Views' menu item you will open an admin interface where you can manage views. But the module name has nothing to do with it. Menu items are translated, but the module name does not have to be. That is not the module name what is displayed in the menu..
Other example 'Book' menu item is translated. Why do we have to translate the module name ('Books'), which is not even the same as the menu item?

+ Module names are essential parts of the d.o infrastructure (now), like you can filter issues by module name. It will not work with translated module names..

module names are translated elsewhere

that's not true. Hungarian translations do not translate module names.. If it is obvious that the text is about the module name, then that string is not translated. But if the text is about the module functionality, like: "view is a list of content", then it will be of course translated, because the text is not about the module name..

"It appears that the <a href=\"@token_link\">Token module</a> is not "
"installed. Please ensure that you have it installed so that Pathauto "
"can work properly. You may need to disable Pathauto and re-enable it "
"to get Token enabled."
msgstr ""
"A <a href=\"@token_link\"><em>Token</em> modul</a> valószínűleg "
"nincs telepítve. E nélkül a <em>Pathauto</em> modul nem tud "
"helyesen működni. A <em>Pathauto</em> modult le kell tiltani, majd "
"ismételten engedélyezni kell a <em>Token</em> modul engedélyezése "
"után."

"You can now <a href=\"!captcha_admin\">configure the CAPTCHA "
"module</a> for your site."
msgstr ""
"Most <a href=\"!captcha_admin\">be lehet állítani a <em>CAPTCHA</em> "
"modult</a> a webhelyen."

msgid "Select the Imagecache preset to use for inlined images in teaser view."
msgstr ""
"Az <em>Imagecache</em> egyik előre beállított értékének "
"kiválasztása az előnézethez."

"The SpamSpan module obfuscates email addresses to help prevent "
"spambots from collecting them.  It implements the technique at "
"http://www.spamspan.com."
msgstr ""
"A <em>SpamSpan</em> modul átalakítja az email címeket, evvel "
"megelőzi, hogy a robotok összegyűjtsék azokat. A "
"http://www.spamspan.com módszerét alkalmazza."

nobody translates "Drupal", I do not see why other project names should be translated..

Names are unique identifiers which should never be translated for the clear and simple reason that they are unique. In a lot of cases they are not words with a meaning, but are just names. If Pasqualle and Gábor came to the Netherlands we wouldn't translate their names to Pascal and Kaboor (or whatever the Dutch translation of Gábor would be) either. Nobody would know who they are anymore.

In Drupal, if we are talking about modules, their names should appear in their original form. Whether we translate menu items like 'Taxonomy' or 'Blocks' is another issue, since in these cases the links could refer to Taxonomy as a practice and to the actual blocks being configured or to the configuration pages of modules. In the first case the items should be translated, in the second they shouldn't.

Conclusion: it has all to do with meaning. As long as a piece of text refers to a module, we should not translate it.

@hass: I do not really understand, what is your point? Are you worried that users will not understand the module name? There is the module description, next to it. I am worried that users won't be able to find the module if we translate it's name, and module name translations will just confuse people..
If someone would ask me about CCK or Views with naming it in Hungarian, I would have no clue what he is talking about. These are the 2 most used modules, and there are 4000 others.
You don't like when your name is translated, then why would you like to translate module names?

For the exotic alphabet. As I know in every language, it is possible to mix Cyrillic, Hebrew, Arabic letters with Latin letters.

Hebrew:

msgid "Your MySQL Server is too old. Drupal requires at least MySQL %version."
msgstr "שרת ה - MySQL ישן מדי. דרופל דורשת גרסה %version ומעלה."

Arabic:

msgid "Your MySQL Server is too old. Drupal requires at least MySQL %version."
msgstr ""
"خادوم ماي.إس.كيو.إل قديم جدا. يحتاج دروبال إلى إصدارة ماي.إس.كيو.إل %version "
"على الأقل."

Russian:

msgid "Your MySQL Server is too old. Drupal requires at least MySQL %version."
msgstr ""
"Ваш сервер MySQL устарел. Drupal требует как минимум MySQL версии %version."

I can't read Hebrew and Arabic, but I would bet that Drupal is Drupal in every language, just the alphabet is different..

If the product is called "MySQL Migration Toolkit", then it should not be translated. If it is a toolkit without a proper name, then it may be translated.

Basic rule: names are never translated in modern day society. Like I said, names don't necessarily have a meaning. They are mere identifiers.

@hass: do you really translate module names like: CCK, Token, Pathauto, CAPTCHA, Imagecache, SpamSpan, FCKeditor, IMCE, Lightbox2, Tagadelic, Wysiwyg API, Acquia Marina, ACL, Diff, Node clone, FeedAPI, Taxonomy Breadcrumb, String Overrides, TAPIr, Auto locale import, Chaos tool suite?

many module names do not mean anything even in English, I don't get it why would it be much more meaningful when it is translated.

If you say yes, then we need a switch (variable) for this..

@hass: Each module has a filename and a descriptive name. The untranslated filenames of the modules are absolutely necessary for an admin to be able to tell which module needs to be uploaded/upgraded/uninstalled etc, without having to decipher how some guy decided to translate a module name while another guy has translated another module name in the same or similar way.

Of course the descriptive module names could be translatable. However the technical limitations of the gettext system must be taken into account: In gettext, if a string is translatable and a translation has been imported, all occurrences of that string anywhere in the site will be translated too. To avoid confusion, the module filenames must appear in the module admin pages, and they must be untranslatable, in case some of them happen to match strings of an imported translation.

Way back when Drupal still translated module names, the Hungarian team did translate them. It was confusing I admit. I'd love to see how hass would translate the module names listed in #24 to German.

Exactly. And now somebody at Drupal.de tells a novice to use Autopfad to solve his problems. That novice visits drupal.org, cannot find that particular module _anywhere_. He logs into IRC, asks around there and everybody tells him that module doesn't exist.

I _really_ don't see the problem here. We as a human race don't translate names for the clear and simple reason (last time I repeat this) that they are UNIQUE indentifiers. Why should we Drupallers differ from that rule?

The arguments against this are compelling. Even the core i18n maintainer admits that when module names used to be translatable it was confusing. Module names are unique identifiers, not meaningful text. The descriptive text both can and should be translatable so that non-English speakers (and English speakers, for that matter) know WTF "CCK" or "CAPTCHA" means. ;) I see no reason to keep debating this.

The problem is that at least 2 issues are waiting for this decision.
#368201: Module name translated
#368197: Module name extracted

So I would like to convince hass, or I don't know, vote on it this issue, so it could be a final won't fix..

I would even accept a switch (a variable or language setting) in D7. So, if German translators decided to translate module names, then they could display it as translated on pages: admin/build/modules, admin/help.. Note: it will not be possible to switch, as full sentence with a module name in it will not use this variable.. We do not want to change sentences like:

t('You may need to disable Pathauto and re-enable it to get Token enabled.')

You translate it as you like.. We just add a check when displaying the module name (means $info['name'])..
Or is it a too complicated solution?

probably languages with exotic alphabet would like to use their own letters like: Друпал
which is not a translation, just a alphabet change, but that needs t() on the string..

Then this isn't postponed waiting for more information from someone. It's being actively debated. I still think it's won't fix, but I'll bow out now and let y'all argue about it.

-Derek

p.s. Oh, how I wish more people were contributing to Death to "+1 subscribe" comments: Help needed so I could unsubscribe myself from this thread...

I definitely do not want to translate module names to Hungarian and it is a problem for me when there is a t() call on module name (as for example "Views" is a general English word and it is translated to Hungarian), but I would accept if some languages want to use t() on it..

@hass #36: (Since I know you're going to submit a duplicate issue about it if I don't tell you): #379470: Change in the issue description is discarded after clicking on the attach button -- blocked on the comment_upload maintainers. <sarcasm>Add some more punctuation there, I'm sure it'll help.</sarcasm> ;)

Also, restoring this to the appropriate status. So long as you people are arguing about this, it's not postponed on anyone. It's active. Please leave it at that status (or better yet, move it back to "won't fix" and be done).

find a project named "Content translation" via "d.o/project/Content translation". You will not see anything

http://drupal.org/node/206666 there is no project named "Content translation" on d.o so I do not understand this example..

http://drupal.org/project/issues?projects=Meta+tags
as you can see I used "Meta tags" (not nodewords) to list all open issues for Meta tags.. Project name is a unique identifier, but it does not really matter in this case..

@hass: do you want a language setting to be able to show module names as translated?

"Content translation" is the .info file "name" of core's translation.module.

@hass
Translated module names would be very confusing imho, it would be even harder to support someone in a different language (german is my native language, btw). Also, each project/module has a Name on d.o. If the modules admin page tells you that you need to install the "Ansichten" module because of a dependency, you would _never_ find it on d.o, neither would anyone in #drupal-support know what you are talking about (Ok, for that one maybe, but not for all the others). Unless d.o is completely translated in every language (and that will never happen), I don't think it's a good idea to do that. The same is true for the other way around, if you would download a module with a specific name from d.o (where the english name is displayed) and then go to /admin/build/modules you would have a hard time to find it, if it has another/translated name there.

As it was pointed out, many modules have names that don't even make sense in english, it's just a name.

Also, most "typical" users probably don't care about the project/something URL, but they would remember the name of the module.

Hass, nobody ever said that module names were unique identifiers used for technical purposes. Humans use names as identifiers. Don't make assumptions.

I don't want to discuss about Views/Ansichten, I just used that as an example, because it's the first translated menu item/name that came to my mind. I could have made the same example with every module that exists. As you said, a "view" is a "Ansicht" in german.

However, "View" (note that the first character) is the name of the module and a different thing.

> That people are not able to find translated module names may be an issue of the "English only" d.o.
That is correct. However, because I really doubt that will ever change, I think it's not a good idea to translate names

Personally, I believe that someone computer-literate enough to administer a site should expect to see "Microsoft Windows" untranslated and "Open a window" translated.

So lets translate module, theme and profile names using t() with context option, because "Друпал" (Drupal with Cyrillic letters) is a good argument why project name should be a translatable string..

I used modules name in order to list them in help section, but I tried to translate them with no success. So I did some changes to the code, that I don't know if they are OK. I only use this feature in the help module, so I think there's no problem with drupal behaviour but I think it can be useful to other modules ... I saw how Drupal parse the file .info so I thought I could change and add a new string definition. For example:

; $Id: search.info,v 1.4 2007/06/08 05:50:55 dries Exp $
name = Search
; Translation into Spanish 2009/09/03
name_es = Búsqueda

Then I did some changes into help.admin.inc and I codified this:

function help_name_translation()
{
  // If the page is in English, it defines the $name as default value, name.
  global $language;

  if($language->prefix == 'en')
    return 'name';
  else
    return 'name_'.$language->prefix;
}

Then, I changed some functions to show the proper name for language.

function help_page($name) {
  $output = '';
  if (module_hook($name, 'help')) {
    $module = drupal_parse_info_file(drupal_get_path('module', $name) .'/'. $name .'.info');
    
    //Variable declaration holding the info type
    $name_tr = help_name_translation();
    //If has no translated name, get the English name
    if($module[$name_tr] == "")
        $name_tr = 'name';
    //Setting the title into the proper language
    drupal_set_title($module[$name_tr]);

    $temp = module_invoke($name, 'help', "admin/help#$name", drupal_help_arg());
    if (empty($temp)) {
      $output .= t("No help is available for module %module.", array('%module' => $module['name']));
    }
    else {
      $output .= $temp;
    }

    // Only print list of administration pages if the module in question has
    // any such pages associated to it.
    $admin_tasks = system_get_module_admin_tasks($name);
    if (!empty($admin_tasks)) {
      ksort($admin_tasks);
      $output .= theme('item_list', $admin_tasks, t('@module administration pages', array('@module' => $module['name'])));
    }

  }
  return $output;
}

function help_links_as_list() {
  $empty_arg = drupal_help_arg();
  $module_info = module_rebuild_cache();
  
 //Variable declaration holding the info type
  $name_tr = help_name_translation();

  $modules = array();
  foreach (module_implements('help', TRUE) as $module) {
    if (module_invoke($module, 'help', "admin/help#$module", $empty_arg)) {
        //If has no translated name, get the English version
        if($module_info[$module]->info[$name_tr] == "")
            $modules[$module] = $module_info[$module]->info['name'];
        else
            $modules[$module] = $module_info[$module]->info[$name_tr];
    }
  }
  asort($modules);

  // Output pretty four-column list
  $count = count($modules);
  $break = ceil($count / 4);
  $output = '<div class="clear-block"><div class="help-items"><ul>';
  $i = 0;
  foreach ($modules as $module => $name) {
    $output .= '<li>'. l($name, 'admin/help/'. $module) .'</li>';
    if (($i + 1) % $break == 0 && ($i + 1) != $count) {
      $output .= '</ul></div><div class="help-items'. ($i + 1 == $break * 3 ? ' help-items-last' : '') .'"><ul>';
    }
    $i++;
  }
  $output .= '</ul></div></div>';

  return $output;
}

I hope this help someone. I don't know if it is useful, but I think it is always a good idea to share the knowledge.

What do you think?

we should just simply use something like

t(module['name'], array(), array('context' => 'Module name'));

the .info file is a wrong place for storing translations..

Module names shoud not translated or display module name under the translated name.

Module names cannot be translated and it seems like 8,132,725 people have argued in length against hass' insane proposal.

Module names cannot be translated, because they are unique.

Module names cannot be translated, because they are a product name.

Module names cannot be translated, because module names may appear in sentences of other modules.

Module names cannot be translated, because they are totally different from menu link titles, which describe the page you may visit, like everywhere else on the net.

Module names cannot be transliterated, because their names are unique.

Thanks for exploring all possible options.

Please stop here, or I'll translate your nickname. ;)

Module names cannot be transliterated, because their names are unique.

Drupal Russian
Drupal Hebrew
Drupal Arabic

The name is still unique. As I know there is not other way to use a different alphabet than making a translation..

"Drupal", the name, is unique, and is the proper name.

The first search result for your Russian example gets it right

- in the domain name

- in the title

- as well as in the text:

Drupal Россия (Drupal Russia)

I'm not even sure whether transliterated names are covered by trademark law (though I guess so, because it's a phonetic variant).

However, to transliterate a name, you don't need t(), because transliteration happens automated.

Just like this is automated:

 ___                      _ 
 | . \ _ _  _ _  ___  ___ | |
 | | || '_>| | || . \<_> || |
 |___/|_|  `___||  _/<___||_|
                |_|          

Now compare that to what you see on http://drupal.org/project/drupal - is it the same? Or is it http://www.dropal.com maybe?

So what is unique, what's not?

transliteration happens automated

I do not know how transliteration can be done in Drupal without using t()..

just for note: I did not know how to write Drupal in Hebrew or Arabic, so I downloaded the translations and tried to find the proper transliteration in it. If Drupal is transliterated then I guess module names needs to be also..

Transliteration is not required. Proof: http://www.drupal.ru/node/32965 - they properly use "Drupal" in Russian text.

Drupal is the name and it is the only, unique representation.

Likewise, no one would assume that Пасяуалле might mean you.

If that was you, then you wouldn't exist on drupal.org.

Hence, Пасяуалле is not Pasqualle.

Just because someone starts to type your name wrong doesn't mean that it's the proper way to type it, neither the proper way to refer to it.

I agree with not translating module names. A while back, the French translation team decided not to translate module names in help text either. As soon as you do, people start to get confused. This problem has been described at length here already, and is by itself compelling enough to declare a won't fix.

please download the Hebrew and Arabic translation and in modules-system.po search for word Drupal.
I do not want to translate module names, and Hungarian does not need transliteration, but if some language needs that, then we should support it.

sun: if you transliterate a word then it is the same. Друпал דרופל دروبال is Drupal, even google knows that. And I am sure if you would correctly transliterate Pasqualle then it would be the same also. But common person names are not transliterated, names have language equivalents.

t($module['name'], array(), array('context' => 'Module name'));

I do not know why can't we support this, so everyone can use it as they like..

as I know Drupal 7 already supports modules name translation.

Drupal more like a product name.
modules is some additional function.

I know MS office/products are not translate their products name, but they translated plugins name.

we can support modules name translation but for Usability reason, we need to display a untranslate name on modules page.

Some people here are missing the point that names are unique. They are not part of a context, they are mere identifiers. There is a difference between "Book" and "book", as the former is a name and the latter a reference to Book(.module) book or something people can read. Menu items may very well be called "Book", but only if the title's a reference to the module. If not, then the word should be translated.

The only valid reason so far is the one that supports not translating module names because they are unique. The arguments raised for translating them are (mostly) based on what has been done in translations and other software projects already. We shouldn't blindly follow others, but make our own decisions.

This issue is not marked won't fix for nothing. Please only (and only!) post follow-ups if you have valid arguments for either standpoint. NO "I'd like" or "but they...".

as I know Drupal 7 already supports modules name translation.

wow, actually you are right!

Let's fix this, because this is so broken now. I need context for these strings, as I do not want to translate module names to Hungarian..

ok, first patch

- I think the sort does not work, because:
http://us.php.net/manual/en/function.strcasecmp.php#24729
http://stackoverflow.com/questions/832709/natural-sorting-algorithm-in-p...

- The update status page is missing from the patch.
- There still must be t($theme->info['name']) somewhere, as Garland is re-inserted into locales_source table without context.

Where is the option that disables this by default and allows to enable it?

Without that, this is not going to fly.

If the given context is not translated, then it is not translated..

I don't understand the necessity of translating module names. You drive away the coders credits. You make it more difficult for the man in middle, working for clients who need to run the site in a certain language. You confuse people talking with experts. You confuse yourself.

I think it is generally wrong to translate them and I translate them every time back for my own usage....

@hass hehe... reading all my points and picking out only the one you don't like... very cool ... :)

I confuse myself always when I install the German translation. Imagine using admin menu, where everything is in a different place when you translated module names. When views is translated into German with "Ansichten" it is not on the bottom anymore.. it sucks and confuses... When I talk with customers over the phone having the German version installed on customers side, while I'm using the English version, I need to guide them totally different to their points. This is a show stopper of the German translation all the time.

We need a living translation and not a 1:1 translation.

Only having a translation for the end user makes no sens, We have to take certain aspects into account. Don't tell us anymore that there are product names which are translated all over the world. Coca Cola remains Coca Cola, even in Germany. Sometimes I hope people wouldn't take this so personal, I know that Hass commits much modules, but there are not only coders around here. There are themers, users, quality leads, mangers, and many many others, and that's what makes Drupal so big. It's not easy to see it from a different point of view. Getting a wider angel on the point... :)

The main problem is that if we decide to translate modules (and I am still very much against that) is that we have no proper documentation that also uses those names, neither does drupal.org use them. +1 confusion.

as hass said it before drupal.org is English. all we need is an option to see the English name of the module also. no confusion, it can be solved easily.

but this is still broken in D7, so this must be fixed. meaning: module names are translated on some places and not translated on some other places..

Alright, if there is a bug, then we need to re-classify this issue accordingly and move a potential feature of translating module names into a new, separate feature request for D8, 9, or 10.

@hass: screenshot in #65

Oh boy. I just looked into my D7 modules page...

That makes zero sense. And I think this issue contains countless of reasons why it doesn't make sense.

Modules are managed by people who know and _have to know_ the proper English names of modules.

+1 for the rollback in D7.

@hass, people are just tired of arguing with you, from what I read.

At this point, despite hass's constant arguing to the contrary, there aren't enough compelling reasons for this change. This will lead to confusion for developers and users working in different languages. I agree with the 'module names are unique identifiers' line of argument above.

- English, Dutch and German. Want me to take a stab at French and Latin as well? Oh, I am a Drupal translator as well.
- Yes, I'm tired of arguing. There are too many people here not posting concrete arguments. Pointing fingers and saying you want what they have doesn't make them right, let alone make you right.
- If nobody argues with you, it doesn't make you right either.
- Microsoft changes some names, but not all. If we translate "External links filter" to "Externe-linkfilter", it makes sense in Dutch. However, names like "Drupal", "Views", or "Pathauto" cannot properly be translated without people raising eyebrows or choking in their lunches.
- Module names are unique identifiers. I'm not calling you "haas" either, because that might be the Dutch translation of your nickname.
- We don't have enough documentation and a website that support translatable module names. People will get confused if they hear different names for the same modules.

Once again: We need concrete reasons for doing something in Drupal; either translate or keep module names. Please keep your mouse pointer as far away from the issue controls until we have enough reasons to go either direction.

You are completely missing the point. We are talking about translating names, not entire web pages. German people who cannot read English don't visit d.o because they don't undestand the entire site. That is a bigger issue than people who don't understand names, identifiers. Please stick to the point. This is one of the reasons hardly anybody even tries to fix this issue; you keep throwing in arguments that have nothing to do with this topic at all.

Gábor today said Címkefelhő instead of Tagedelic. I do not need a better reason..
Module and Theme names needs to have t() with context. There needs to be a way to display the original project names (+English names) on the admin pages..

or missed the people asking on drupalcenter.de for help explicitly for the reason they do not speak English (and they tell us).

If you would have been more active on drupalcenter or in IRC in the last months you would have noticed that the main confusion comes from translated module names and not from being not able to understand english!

Only think about east Germany... Russian was their second language in school. I would wish I could speak Russian myself...

Bad example. I had russian in school several years but I really don't want to have customers telling me they have a problem with "просмотр" or something like this.

I fully agree with sun! "Modules are managed by people who know and _have to know_ the proper English names of modules."

What would you tell a client if he wants to display nodes in a different style? "Laden Sie Ansichten herunter"? I guess not. You would call him to "download views". And if he do so he would really be confused if the name changes to "Ansichten".

So please do not translate module and theme names. You wouldn't want to translate your family name, wouldn't you?

Then we are able to write Das Ansichten-Modul muss heruntergeladen werden.

You can't be serious?! Go and find the module "Ansichten" at drupal.org/Modules. Or tell your customer to find and download it.

We also do not write "Sie" or "Du" in German translations!

That was not the point of my example (that was no translatable string but something one may say to a customer).

what you are complaining about regaring Views is the result of the bad basis of translatable strings only

No. Its about translating Views and other module/theme names.

Have you ever tried to help me translating Views to German?

Yes, I did. That was before our "talk" at cologne earlier this year. After that I stopped helping you going in this direction.
And as I noticed you didn't change your mind since then so this is a won't fix for me. Module and Theme names must not be translated.

yes, hass keeps missing the point.

Reverting issue properties to a feature request.

We'll remove translations of module/theme names in #632896: Rollback translation of module names

Laden Sie Ansichten herunter

This should of course be Laden Sie Views herunter.

@Hass: please keep your mouth shut if you cannot do anything but criticise the current situation and not suggest anything that can actually solve this issue. You keep wanting to push this into D7 at all cost, even though we keep saying that is not possible because drupal.org and other documentation do not support this. That doesn't even have to do with if we want this or not, but with the chances of actually making such a change work.

Basically, what you want requires a change at drupal.org and in major documentation articles *before* we can change Drupal itself, otherwise people will get lost.

Not that this changes the way I think about this issue, but I must admit I still don't quite understand why you have such an urge to see this changed. As a German you will have no difficulties with reading module names, although you may not understand them, but that is the case with a lot of foreign names (unique identifiers).

no change to d.o is necessary, d.o is English only and will be English only. Module name translation is a valid feature request, which will be solved sooner or later..

It is a valid feature, but if people using Drupal see translated module names, but cannot find modules with those names on drupal.org, we create a bigger mess than we have now.

but if they can see non-translated names in Drupal when they want to....

I am also free to call you John or Edgar, but most people will not expect that I am talking about hass. This is not about technical limitations, but about UX limitations.

We can stop worrying now. #632896: Rollback translation of module names is in.

Now I'd really like to unsubscribe here. :-/

As a consequence, this is won't fix.

I gave you a valid reasons why some languages needs this, I do not see any rejections to my request, so this is active, and need to be fixed someday..

Nope, doesn't really have much to do with this issue.

Just because Microsoft chose to rename one of their products for marketing reasons in a foreign country doesn't mean we should automatically translate module names within Drupal.

Most if not all module names are based on an English word or phrase, so there will be less confusion in other languages than with names that are 'just made up'.

@Xano: in your last comment it is not clear that you are supporting or you are against this feature. I do not need an explanation just wanted to tell that it is quite funny..

So far I'm against it (read my earlier comments). With #108 I just wanted to point out that Microsoft's issue with Bing in China is less of a problem for Drupal than it was for Microsoft and that it doesn't hold as much value as an argument as some might think.

@hass:

It was marketing. 'Bing' was a poor name in that country, so they are marketing under a different name.

While it may be possible that there is a module name which is a defamation or obscene in another language, I challenge you to find one. When it comes down to it, I don't see how giving people the ability to translate module names can be justified given the added complications it will make in the support forums.

Can you tell me why I can't get 'Obsah stavebnici' to work? What about 'Vaatamisi'? Or 'žetoon'? Where on Drupal can I find the pages for these modules? For the curious, these are 'Content Construction Kit', 'Views', and 'Token' in different languages.

The only possible way I see to do this is to include both the translated and English name on the module page, and tell people to use the English name when they ask support questions. However, I can see that suggestion putting the UX crew into fits...

I assume you mean machine names when talking about raw module names. The meaning of those is that they're machine names and not meant to be displayed in the UI. Also, calling a module "Meta tags" while its machine name is "nodewords" is just plain stupid. Allowing module name translations for this is fighting symptoms and IMO no argument at all for adding this feature. UX shouldn't become worse because of programmers' imcompetence.

What if we allow module name translations and use Bing as an argument. I agree this can be a practical use case and it looks like a valid reason. The problem with this is we might get idiots who go and translate all module names without there b(e)ing any need for that, only making support and UX worse.

Question in Short:

Is it save to translate module names in the UI now without destroy what we call system name nowerdays and drive away credits from the developers?

Oh my,

it seems this a very emotional topic so i am a bit afraid to comment on it. But I need some help regarding this topic.

Could some of you verify that we are able to translate UI strings now at 100% without harming people and harm the process to search and find modules project pages and documentations on drupal.org by using Google and other search engine.

By translating the General Data Protection Regulation Module for Drupal 8 to German I find out the following so far:

By now module names are not translated on the following pages even if a project is translated 100%

1. /admin/modules
2. /help
3. /admin/index
4. /admin/reports/updates

That's totally fine!

People can find project pages on Drupal.org now, at least if they know how to find them.

The Problem with this is that there is a myth spread by some participants of the German translation team:

„Do not translate module names at all, because the name of a Module is a Trademark“

I believe that isn't true anymore. But maybe I am wrong. Here is an example:

The abbreviation for General Data Protection is GDPR in German it is DSGVO for (Allgeimene) Datenschutz-Grund Ver-Ordnung.

Individuals (non-coders) may have a problem if such Strings are not translated. At least it may take a bit longer till they understand what the configuration options and fields are doing, when they see GDPR instead of DSGVO in a menu or somewhere else on the UI.

So could you confirm that module names will be English in Drupal 8 and Drupal 9 even if a module is translated to 100 % on the pages named above?

If we find a way to tell people how to find Module/Project Pages by using system (English) names I think we can debunk the myth of the trademarked module name.

This is especially important when it comes to write some guide lines for new translators and reviewers. I like to do so to make sure more individuals will be able to translate core and community modules without harming the UI too much and make it as clear and intuitive for new users and potential customers as well.

There are many other models like the module Flag or even Paragraphs where it may be better to use a word in your own language that describe what sth. does e.g. a collection of paragraph components is not a <p>paragraph</p> at all. So this is still a UX problem.

That's why I am asking here. I hope it is understandable enough and well not lead to a discussion like the discussion you had above.

Closed duplicate issue.

This feature request has been closed and re-opened quite a few times! But there has been no discussion for 8 years, that is discounting the question 4 years ago.

Comment #102 reported that the related issue #632896: Rollback translation of module names the translation of module names was reverted. Some reasons for that decision and suggestions for implementing a solution are In comment #5 of that issue.

Therefor I am closing this as working as designed.