"anonymous user" and "authenticated user" are not translateable

the same problem apeared in 4.6.2.
But I can change the role's name from database without any error.
Isn't user system asign the role name by rid number? why it should be lock?

在 4.62 裡一樣也不能翻譯
但我能從資料庫裡面變更角色名稱而且沒有任何錯誤
user system 不是靠 role 裡的 rid 指派的嗎?為什麼需要 lock 起來?

+1 from me.

+1 from me.

I'm not exactly sure, but doesn't this make *all* roles translatable? Also the user inputted user roles?
If that's the case, I don't think this is a good idea..

Yup, you are right..
I like your patch, and the fact that you renamed the function user_roles() to user_get_roles() is much more drupal-like, and inline with all the other *_get_*() functions..

I tested this now, and there is nothing that doesn't work. The roles for anonymous and authenticated users can finally be translated.

From a code pov I can not find anything that doesn't look right, or doesn't follow our coding guidelines. Nice work!

This is RTBC!

We are in code-freeze mode, so renaming of this function does not seem to be possible (and it does not look like a requirement or a necessity, but only a "cosmetic" kind of change). Otherwise, the boolean typing and renaming of the first param and the NULL default of the second param is a good idea. This kind of translation also makes sense to me, so let's get this to a shape (with some testing) in which I can commit it post-code-freeze.

I am getting following error message when applying the patch:

Hunk #1 succeeded at 1327 with fuzz 1 (offset -127 lines).
Hunk #2 succeeded at 1745 (offset -149 lines).
Hunk #3 succeeded at 1764 (offset -149 lines).
Hunk #4 succeeded at 1800 (offset -149 lines).
Hunk #5 succeeded at 1895 (offset -149 lines).
Hunk #6 succeeded at 1913 (offset -149 lines).
Hunk #7 succeeded at 1979 (offset -151 lines).
Hunk #8 FAILED at 2036.
Hunk #9 succeeded at 2156 (offset -150 lines).
Hunk #10 succeeded at 2470 with fuzz 1 (offset -376 lines).
1 out of 10 hunks FAILED -- 

The rejects are:

***************
*** 2030,2036 ****
    $destination = drupal_get_destination();
  
    $status = array(t('blocked'), t('active'));
-   $roles = user_roles(1);
    $accounts = array();
    while ($account = db_fetch_object($result)) {
      $accounts[$account->uid] = '';
--- 2036,2042 ----
    $destination = drupal_get_destination();
  
    $status = array(t('blocked'), t('active'));
+   $roles = user_get_roles(TRUE);
    $accounts = array();
    while ($account = db_fetch_object($result)) {
      $accounts[$account->uid] = '';

Why this error?

Don't get this patch working with site_userlist module.

Yup, this needs updating

$ patch -p0 < user-translate-roles.patch
patching file modules/upload/upload.admin.inc
patching file modules/user/user.admin.inc
Hunk #1 succeeded at 173 (offset 7 lines).
Hunk #3 succeeded at 621 (offset 8 lines).
patching file modules/user/user.module
Hunk #1 FAILED at 1314.
Hunk #2 succeeded at 1602 (offset 103 lines).
Hunk #4 FAILED at 1553.
Hunk #5 succeeded at 1853 (offset 104 lines).
2 out of 5 hunks FAILED -- saving rejects to file modules/user/user.module.rej

Would be great to get #206078 in before, cause it deals with the same code and is rtbc IMHO. Immediately thereafter I'll update this patch here.

edit: I updated the code. Just waiting to get #206078 in, then I can post an applying patch.

After #206078 has been committed, I provide an updated patch.
I left out the part that has been fixed in #206078.
Also, in user_roles() I moved the if-clause (checking $membersonly) inside the switch-clause, to make sure every condition is checked only once (= cleaner & a tiny little bit faster).

- 1 to TRUE and 0 to FALSE changes look good, as this is how the API works as documented
- $permission default to NULL introduces a notice on the if($permission) line, it should use !empty() (which also accomodates any code which might pass on FALSE or '' here)
- add a comment to the DRUPAL_AUTHENTICATED_RID and DRUPAL_ANONYMOUS_RID cases, that // We only translate the built in role names

Don't know why, but if($permission) didn't introduce a notice for me. I anyway changed it to if(!empty($permission)). Also added the comment.

(deleted duplicate)

Thanks, committed this one.

Oh, this broken role name editing and was fixed by committing this small patch. I should have been more alert on what goes on here, sorry...

I'm sorry, I should have tested my patch better...
thanks for committing and thanks for fixing role name editing!

Why is it not a good idea to make *all* roles translatable.

I am running into this issue, because I want all roles to be translatable.

Couldn't the option be given to the admin, and if they do not supply a translation, then it will show the default value.

Drupal itself does not have a built-in facility to translate user provided data. It has some low level database support, but nothing on the user interface and nothing on the API levels. The i18n module does that. See http://drupal.org/node/304002

Reading common.inc, found the reasons for not translating user provided data, thank you.

I am wondering if there was interest for making i18n / strings part of drupal core. I guess 7 is too late, but maybe 8?

It seems partially counter-intuitive to provide translatability in core of some static strings, but not admin/user generated strings, because of t()'s inability to clean up after itself, and the way that translation files are generated.

Also role names, or content type names/ labels, although a user can modify them, seem a bit caught in no mans land, as the users that can edit these things would be admins rather than everyday users.

--- nevermind, these discussions are happening with yched, nedjo, plach, etc.
http://drupal.org/node/549698
http://drupal.org/node/357529

--- and other i18n discussions with Gábor Hojtsy, Jose A Reyero and Roberto Gerola
http://drupal.org/node/141461