Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
#18954-28: "anonymous user" and "authenticated user" are not translateable implies it should be possible to translate role names with i18n, however from looking at http://api.drupal.org/api/function/user_edit_form/6 and http://api.drupal.org/api/function/user_roles/6 it looks as though core actually gives no opportunity for their translation? Also the comment in user_roles() "We only translate the built in role names" is a bit ominous...
(This is in response to #301541-11: Contact form and Roles names are not translatable !)
Seems to be the same in 7.x also.
Comment | File | Size | Author |
---|---|---|---|
#55 | custom-roles-not-translatable-d7-598862-55.patch | 424 bytes | LeDucDuBleuet |
#15 | 598862-roles-d7.patch | 1.73 KB | andypost |
#14 | 598862-roles-d7.patch | 1.88 KB | andypost |
Comments
Comment #1
mairav CreditAttribution: mairav commentedSubscribing. I hope there can be a solution to this in i18n or in core.
Comment #2
Jose Reyero CreditAttribution: Jose Reyero commented"it looks as though core actually gives no opportunity for their translation?"
Right
Comment #3
gpk CreditAttribution: gpk commentedThanks, let's file this as a bug against core then!
In #18954-28: "anonymous user" and "authenticated user" are not translateable Gabor seems to think that it would be possible for i18n to pick up user role names and translate them. But they are never run through t(), either in http://api.drupal.org/api/function/user_roles/7 or http://api.drupal.org/api/function/user_account_form/7 hence there is no way of modifying them via the language system.
Comment #5
plachThere is a lot of discussion related to this in other issues. The most promising solution currently is #593746: Prepare Drupal core for dynamic data translation.
I am afraid this cannot be considered a bug report but a feature request, and as such it should be addressed in D8.
Comment #6
blueblade CreditAttribution: blueblade commenteddo you guys think that this feature will be available for Drupal6 also, and soon?
Comment #7
plachI'm sorry but I don't think this will be addressed in D6, you'll have to rely on the i18n project.
Comment #8
gpk CreditAttribution: gpk commented@7, @5: unless I'm mistaken (which is not unheard of) it is still not possible to translate custom user role names by any means whatsoever (including i18n) because they are not run through t(). As such this would be a bug.
Comment #9
plachUser-entered strings are not supposed to pass through t() so we must find another way. You can keep considering it a bug, but this is an ability that Drupal currently does not have and not some component that is misbehaving.
Comment #10
gpk CreditAttribution: gpk commented@9: Ah, I see the problem, thanks. I'm not familiar enough with the translation internals to take a view on whether this omission should be filed against core or i18n (I guess it's one of those details that has fallen between 2 stools), or what sort of solutions might be appropriate. At least people can find it here and see that it is a current problem for 7.x and earlier.
Comment #11
plachAs I was saying this cannot be considered a bug.
Comment #12
plachActually it seems user roles cannot be translated neither through DDT, give a look to http://api.drupal.org/api/function/user_roles/7.
Comment #13
andypostMaybe just add "translatable" tag to query and schema definition?
Comment #14
andypostLet's try this one
Comment #15
andypostA bit simplified patch
This could lead to double translation with DDT but I see no other way
Comment #16
plach@andypost:
The patch looks good to me: could you please explain why?
Comment #17
andypost@plach because rolenames for RID 1 and 2 are passed through t() in http://api.drupal.org/api/function/user_roles/7
EDIT sorry, I mean RID 1 (DRUPAL_ANONYMOUS_RID) and 2 (DRUPAL_AUTHENTICATED_RID)
Comment #18
plach@andypost: We could easily leave DRUPAL_ANONYMOUS_RID and DRUPAL_AUTHENTICATED_RID untranslated in DDT so that t() gets the built-in english values.
IMO this is RTBC, but I'd like sun to confirm.
Comment #19
sunThanks, looks good.
Comment #20
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks.
Comment #21
mairav CreditAttribution: mairav commentedIs there a way to backport this to Drupal 6? So we can have this working until Drupal 7 can be used on production sites?
Comment #22
andypostThis approach could not be ported to D6, so proceed with #301541: Contact form and Roles names are not translatable !
Comment #24
EugeneChechel CreditAttribution: EugeneChechel commentedcreate hook_form_alter then add there something similar to
foreach ($form['account']['roles']['#options'] as $key => $value) {
$form['account']['roles']['#options'][$key] = t($value);
}
depends on your form. Then translate it
Comment #25
yuseferi CreditAttribution: yuseferi commentedgood job, Thank you
Comment #26
fraweg CreditAttribution: fraweg commentedHello,
I use this patch but it seems not to work. Am I right that after this patch user rolls should be translatable as a string translation?
Many thanks for any Help!
Best regards
Frank
Comment #27
tierso CreditAttribution: tierso commentedHas this yet been worked into drupal, or does it still have to be applied as a patch? (I am unable to find a way to translate roles).
Comment #28
fraweg CreditAttribution: fraweg commentedSo when I am not alone with this issue this thread should be set to active..am I right?
Best regards
Frank
Comment #29
fraweg CreditAttribution: fraweg commentedComment #30
sunFor D7, the committed patch is all we can do.
For D8, we hope to be able to have user roles in configuration, and we also hope to have translatable string support for configuration (in general).
Comment #31
fraweg CreditAttribution: fraweg commentedBut the question why the patch seems to work for some and not others remains open...Too bad I thought it would be a possibility to.
Best regrads
Comment #32
patkai CreditAttribution: patkai commentedThe reason might be a simple misunderstanding. As the code comment in modules/user/user.modules shows only built in role names are translatable. So it works for those who try to translate those and does not for those who have custom role names :)
Comment #33
fraweg CreditAttribution: fraweg commentedHello,
and is there a solution for that ?
Best regards
Frank
Comment #34
patkai CreditAttribution: patkai commentedAs the code comment suggests this is intentional, but I'm not yet sure why. I'm looking for a way to do the translation without a core hack... Will get back to you when I understand this fully.
Comment #35
tierso CreditAttribution: tierso commentedIt would be interesting to find out from the original coder what the intention was (if anything else but lack of time/effort; it's seemingly a very minor issue). An oddly multilingual-unfriendly decision, and even stranger that this is issued is being put into the forget-bin considering the increased efforts to make drupal fully "internationalized".
Comment #36
deadbox CreditAttribution: deadbox commentedHas anybody found a way to translate custom user roles yet? I am creating a bilingual site where users are added to a custom role with extra permissions after they take out a paid subscription. When they've paid it seems very unprofessional not to show them their role in their own language.
Comment #37
mas0h CreditAttribution: mas0h commentedAny update on this? I can't translate user roles.
Comment #38
wangjiaqi CreditAttribution: wangjiaqi commentedI create a simple module to translate the role name without any core hack. Hope it will help you. https://drupal.org/sandbox/wangjiaqi/2222171
Comment #39
mas0h CreditAttribution: mas0h commentedThank you wangjiaqi, I will test and give you feedback.
Comment #40
mas0h CreditAttribution: mas0h commentedDoesn't work, after installing and going to translation page I only get the built-in roles
Comment #41
wangjiaqi CreditAttribution: wangjiaqi commentedhi mas0h
1. I don't allowed user translate anonymous user/authenticated user in this module. It's translated by system po file.
2. if you set 'en' as your default language and this list page is 'en' in the same time, role name won't be translated.
How it works:
eg.
1. Create a new role name 'mas0h test'
2. Set 'en' as your default language and 'fr'(or any language you want to translate) as your admin language
3. Go back to the config page, now the 'translate' after 'mas0h test' will be a link, edit that.
Comment #42
mas0h CreditAttribution: mas0h commentedGreetings wangjiaqi,
When I view the translation page for roles in the other language, now I see all my roles with translation links not active, just text.
Comment #43
libruce CreditAttribution: libruce commentedmake sure you are going to translate the custom roles, except the built-in roles (anonymous user/authenticated user)
Comment #44
wangjiaqi CreditAttribution: wangjiaqi commentedHi mas0h, thks for your reply. I will fix this bug a.s.a.p
Comment #45
kopeboy CreditAttribution: kopeboy commentedDrupal core permits us to create custom user roles.
Those are not translatable.
Looks to me this issue isn't fixed.
Comment #46
kopeboy CreditAttribution: kopeboy commentedCan we have some attention on this?
This is hilarious.. come on!
Comment #47
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedWhat is the remaining issue that needs to be fixed here?
As I understand it:
So is there anything that still needs to be changed in core to allow this to work properly in contrib?
Comment #48
paucku CreditAttribution: paucku commentedMy solution: I have passed the user role names trough t() function for translation. Works for now. I will write here if something breaks caused of that. It is very easy to do, so in the next upgrade of Drupal Core I will do it again (or will try to merge the new Core using Git).
In function user_roles($membersonly = FALSE, $permission = NULL) which is in file user.module I changed that:
into that:
Comment #51
LeDucDuBleuet CreditAttribution: LeDucDuBleuet as a volunteer commentedCan somebody please explain why the working solution in comment #48 is not a good solution?
Thank you
Comment #52
geek-merlinYes please read here:
Translating user-defined strings | Drupal.org
Comment #55
LeDucDuBleuet CreditAttribution: LeDucDuBleuet as a volunteer commentedThanks @axel.rutz but let me explain myself a little better.
What I do not understand is why do we translate only built-in roles in core for D7? I cannot find a clear answer to this simple question?
This is forcing us to use a sandbox module which seems overcomplicated for nothing in my opinion. Especially when the solution like in #48 would be very simple to apply in core so we could translate custom roles using the standard admin interface at "admin/config/regional/translate/translate". All roles would be translatable the same way, no need to use a separate page for custom roles.
Please review the patch attached so we can understand better.
Thank you.
Comment #56
luismagr CreditAttribution: luismagr as a volunteer and at Front ID commentedI have reviewed the patch and it works fine for me. Thanks.
Comment #57
geek-merlinLong story short: I18n must be used so that a user-change of the source string won't break translation.
Comment #58
RoslinMary CreditAttribution: RoslinMary at DrupalPartners for Innoppl Technologies Pvt. Ltd commentedUsing I18n will provide "String translation" to change the provided string in mentioned language.
Comment #59
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedI think another problem with the patch is that t() assumes the input string is in English. But if someone has a site where (for example) Spanish is the primary language for the admin UI, they're going to create their role names in Spanish. Passing those through t() would mean that the Spanish role names show up in the translate UI as "English" strings that need to be translated to Spanish...
Comment #60
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedI am going to retitle this issue slightly to clarify why it is still open, although I do think closing it may still be the best course of action here; as noted previously, a patch was committed to Drupal 7 a very long time ago to enable role translation via contrib modules, and there is no indication that that process does not work.
If someone can figure out a way to improve this further in core, it could be considered, but I am not sure how without running into the problems discussed above? I do see how something like the patch in #55 can be useful as a site-specific solution, but in its current form it doesn't look like something which could be committed, due to the more general problems mentioned above.
Comment #61
marksmith CreditAttribution: marksmith commentedCustom role names did not show up for me among user defined strings in i18n. As per #55, this solution works, but if you need the field translated in Views as well, you have to modify views_handler_field_user_roles.inc.
somewhere around line 46:
change
$this->items[$role->uid][$role->rid]['role'] = check_plain($role->name);
into:
$this->items[$role->uid][$role->rid]['role'] = check_plain(t($role->name));