[drupal-devel] Web Spam Summit - can anyone make it to this?
Hi: I direct your attention to this: http://jeremy.zawodny.com/blog/archives/004256.html It's right in the middle of DrupalCon, but it would be fantastic if someone from the community could attend. Chris Messina? Zack? Anyone? -- Boris Mann http://www.bryght.com
There should be an effort to externalize all english text into default variables. It makes a great step towards true internatiolization. Does not cost anything in terms of performance or matainance. What it does do is make the code that uses hard coded strings open and more resuable. It adds the flexibility in phrasology that is necessary in internationalizing Drupal. It creates more usability in that better text instructions can be delivered to the user based on the situation of the process. I have made this slight change in my install which allows me to give a descriptive message based on the url tried. This can be done in both english and swedish without me having to use gettext and the like I also feel that this should be added to the coding conventions so that Drupal code will keep moving forward into internationalization and need less "fixing" inorder for it to happen properly. I have created an issue and patch on this but I thought it should be addresses directly as many will be branching their code for v4.6 and this should be part of that. --- common_1.inc 2005-02-19 17:33:21.451910400 +0100 +++ common_2.inc 2005-02-19 17:34:40.876116800 +0100 @@ -427,8 +427,8 @@ function object2array($object) { * Always consider whether to use drupal_access_denied() instead to return a * proper (and customizable) 403 error. */ -function message_access() { - return t('You are not authorized to access this page.'); +function message_access($message = 'You are not authorized to access this page.') { + return t($message); }
Maybe my head is just a brick, but I fail to understand how this will help. Could you please explain to us how would the translation process work in this case? Regards Karoly Negyesi On Saturday 19 February 2005 19.15, Carl McDade wrote:
There should be an effort to externalize all english text into default variables. It makes a great step towards true internatiolization. Does not cost anything in terms of performance or matainance. What it does do is make the code that uses hard coded strings open and more resuable. It adds the flexibility in phrasology that is necessary in internationalizing Drupal. It creates more usability in that better text instructions can be delivered to the user based on the situation of the process. I have made this slight change in my install which allows me to give a descriptive message based on the url tried. This can be done in both english and swedish without me having to use gettext and the like
I also feel that this should be added to the coding conventions so that Drupal code will keep moving forward into internationalization and need less "fixing" inorder for it to happen properly.
I have created an issue and patch on this but I thought it should be addresses directly as many will be branching their code for v4.6 and this should be part of that.
--- common_1.inc 2005-02-19 17:33:21.451910400 +0100 +++ common_2.inc 2005-02-19 17:34:40.876116800 +0100 @@ -427,8 +427,8 @@ function object2array($object) { * Always consider whether to use drupal_access_denied() instead to return a * proper (and customizable) 403 error. */ -function message_access() { - return t('You are not authorized to access this page.'); +function message_access($message = 'You are not authorized to access this page.') { + return t($message); }
I have created an issue and patch on this but I thought it should be addresses directly as many will be branching their code for v4.6 and this should be part of that.
--- common_1.inc 2005-02-19 17:33:21.451910400 +0100 +++ common_2.inc 2005-02-19 17:34:40.876116800 +0100 @@ -427,8 +427,8 @@ function object2array($object) { * Always consider whether to use drupal_access_denied() instead to return a * proper (and customizable) 403 error. */ -function message_access() { - return t('You are not authorized to access this page.'); +function message_access($message = 'You are not authorized to access this page.') { + return t($message); }
Why do you have message_access() now, where you originally intended to have t()? Using t() is simpler! Goba
It's just one of many stages of getting the localization/internationalization process out of the Drupal core and have it handled more by the contributed modules. "You are not authorized to access this page" is hardcoded in a core structure piece, common.inc which means that conmmon.inc needs a PO file for translation. But now a decision has to be made on how to phrase and use this message because it will come up at every "access denied" situation. Ones where login is incorrect to those where a hack attempt is being made. By moving the string over to a variable and using it only as a default only the module calling the function will need to be translated using (english for this example): message_access('You/she do not have access rights in this area please check with the administrator') but in another section this may not be apporproíate language and need to be said in a different manner. message_access('You/They are not allowed access to this area please because of an error in linking') Carl McDade
Maybe my head is just a brick, but I fail to understand how this will help.
Could you please explain to us how would the translation process work in this case?
Regards
Karoly Negyesi
On Saturday 19 February 2005 19.15, Carl McDade wrote:
There should be an effort to externalize all english text into default variables. It makes a great step towards true internatiolization. Does not cost anything in terms of performance or matainance. What it does do is make the code that uses hard coded strings open and more resuable. It adds the flexibility in phrasology that is necessary in internationalizing Drupal. It creates more usability in that better text instructions can be delivered to the user based on the situation of the process. I have made this slight change in my install which allows me to give a descriptive message based on the url tried. This can be done in both english and swedish without me having to use gettext and the like
I also feel that this should be added to the coding conventions so that Drupal code will keep moving forward into internationalization and need less "fixing" inorder for it to happen properly.
I have created an issue and patch on this but I thought it should be addresses directly as many will be branching their code for v4.6 and this should be part of that.
--- common_1.inc 2005-02-19 17:33:21.451910400 +0100 +++ common_2.inc 2005-02-19 17:34:40.876116800 +0100 @@ -427,8 +427,8 @@ function object2array($object) { * Always consider whether to use drupal_access_denied() instead to return a * proper (and customizable) 403 error. */ -function message_access() { - return t('You are not authorized to access this page.'); +function message_access($message = 'You are not authorized to access this page.') { + return t($message); }
1) whats wrong with t()? Its the default in a lot of environments, its use has been weighted, and proven bets. 2) if you encounter any non-translated strings, that is a bug. Please report these bugs. Bèr
I had forgotten about the use of t() but that is not a problem when diog this. Since the common.inc is not involved any longer the pratical use of t() and in keeping with the use of gettext in the contrib module would be: print theme("page", message_access(t('Please login or register to see this material')), t("Access denied")); This means that the core item common.inc only has to be changed once to allow for the (default or variable) and would never need a PO file or gettext. This is a pick up in performance for common.inc that offsets any losses for a call to a string variable. Carl McDade Bèr Kessels wrote:
1) whats wrong with t()? Its the default in a lot of environments, its use has been weighted, and proven bets. 2) if you encounter any non-translated strings, that is a bug. Please report these bugs.
Bèr
Second guessing but, Can someone tell me why this is like this: print theme("page", message_access(), t("Access denied")); rather than this? print theme("page", t('Please login or register to see this material'), t("Access denied")); Why is there a call to a Function like this anyway? Is is a mistake in the filestore2 module or is this something that has to be used? I noticed this after killes posted. Is this legacy code and should be removed? Carl McDade Carl McDade wrote:
I had forgotten about the use of t() but that is not a problem when diog this. Since the common.inc is not involved any longer the pratical use of t() and in keeping with the use of gettext in the contrib module would be:
print theme("page", message_access(t('Please login or register to see this material')), t("Access denied"));
This means that the core item common.inc only has to be changed once to allow for the (default or variable) and would never need a PO file or gettext. This is a pick up in performance for common.inc that offsets any losses for a call to a string variable.
Carl McDade
Bèr Kessels wrote:
1) whats wrong with t()? Its the default in a lot of environments, its use has been weighted, and proven bets. 2) if you encounter any non-translated strings, that is a bug. Please report these bugs.
Bèr
Second guessing but,
Can someone tell me why this is like this:
print theme("page", message_access(), t("Access denied"));
rather than this?
print theme("page", t('Please login or register to see this material'), t("Access denied"));
Why is there a call to a Function like this anyway? Is is a mistake in the filestore2 module or is this something that has to be used? I noticed this after killes posted. Is this legacy code and should be removed?
The role of this was not to repeat the same t() at multiple places. But see the patch submitted by Killes. It is a good step forward. You proposed to change message_access() to function message_access($message = 'You are not authorized to access this page.') { return t($message); } Which would be easy to reduce to a single t() call instead of passing a string into message_access, and that single t() call would actually enable the automatic translation template generation, unlike this solution you proposed. Goba
This is something that should be addressed for the next release. I don't have all modules installed. But a search through the ones I have turned up 31 calls to message_access. Even node has one. Or does it have to be done on a module by maintainer level? Regardless I am cleaning out the baggage from my code. Carl McDade Gabor Hojtsy wrote:
Second guessing but,
Can someone tell me why this is like this:
print theme("page", message_access(), t("Access denied"));
rather than this?
print theme("page", t('Please login or register to see this material'), t("Access denied"));
Why is there a call to a Function like this anyway? Is is a mistake in the filestore2 module or is this something that has to be used? I noticed this after killes posted. Is this legacy code and should be removed?
The role of this was not to repeat the same t() at multiple places. But see the patch submitted by Killes. It is a good step forward. You proposed to change message_access() to
function message_access($message = 'You are not authorized to access this page.') { return t($message); }
Which would be easy to reduce to a single t() call instead of passing a string into message_access, and that single t() call would actually enable the automatic translation template generation, unlike this solution you proposed.
Goba
What do you mean by 'this'? What should be addressed. I still fail to see your goal. Goba
This is something that should be addressed for the next release. I don't have all modules installed. But a search through the ones I have turned up 31 calls to message_access. Even node has one.
Or does it have to be done on a module by maintainer level?
Regardless I am cleaning out the baggage from my code.
Carl McDade
Gabor Hojtsy wrote:
Second guessing but,
Can someone tell me why this is like this:
print theme("page", message_access(), t("Access denied"));
rather than this?
print theme("page", t('Please login or register to see this
material'),
t("Access denied"));
Why is there a call to a Function like this anyway? Is is a mistake
in
the filestore2 module or is this something that has to be used? I noticed this after killes posted. Is this legacy code and should be
removed?
The role of this was not to repeat the same t() at multiple places. But see the patch submitted by Killes. It is a good step forward. You proposed to change message_access() to
function message_access($message = 'You are not authorized to access this page.') { return t($message); }
Which would be easy to reduce to a single t() call instead of passing a string into message_access, and that single t() call would actually enable the automatic translation template generation, unlike this solution you proposed.
Goba
According to Killes bug report the use of message_access is legacy and should not be there. Yet it is there in some core and contributed modules. Shouldn't that be fixed? Even moving them up into the module level from common.inc message() to t() would be a help in promoting usability and translation. Carl Gabor Hojtsy wrote:
What do you mean by 'this'? What should be addressed. I still fail to see your goal.
Goba
This is something that should be addressed for the next release. I don't have all modules installed. But a search through the ones I have turned up 31 calls to message_access. Even node has one.
Or does it have to be done on a module by maintainer level?
Regardless I am cleaning out the baggage from my code.
Carl McDade
Gabor Hojtsy wrote:
Second guessing but,
Can someone tell me why this is like this:
print theme("page", message_access(), t("Access denied"));
rather than this?
print theme("page", t('Please login or register to see this
material'),
t("Access denied"));
Why is there a call to a Function like this anyway? Is is a mistake
in
the filestore2 module or is this something that has to be used? I noticed this after killes posted. Is this legacy code and should be
removed?
The role of this was not to repeat the same t() at multiple places. But see the patch submitted by Killes. It is a good step forward. You proposed to change message_access() to
function message_access($message = 'You are not authorized to access this page.') { return t($message); }
Which would be easy to reduce to a single t() call instead of passing a string into message_access, and that single t() call would actually enable the automatic translation template generation, unlike this solution you proposed.
Goba
On Sat, 19 Feb 2005, Carl McDade wrote:
According to Killes bug report the use of message_access is legacy and should not be there. Yet it is there in some core and contributed modules.
The patch takes care of the core modules (node, blogapi).
Shouldn't that be fixed?
If the patch gets accepted the contributed modules will need to get updated. Contrib maintainers are of course free to not use message_access() without this patch. Cheers, Gerhard
According to Killes bug report the use of message_access is legacy and should not be there. Yet it is there in some core and contributed modules. Shouldn't that be fixed? Even moving them up into the module level from common.inc message() to t() would be a help in promoting usability and translation.
It is not an error to use message_access(), nor does it introduce translation problems as you tried to suggest. It does introduce useability problems in the sense that it does not provide the specific reasons for some failure. Goba
In english maybe it effects just usability but in cases like this I don't think that usability and translation are exclusive of each other. If you can't get good translation in a particular situation then it effects usability immediately. Use of message_access() is not wrong, but it is legacy it would seem. In my opinion any opportunity to replace legacy code and make things simplier should be taken. They don't come around often. Carl McDade Gabor Hojtsy wrote:
According to Killes bug report the use of message_access is legacy and should not be there. Yet it is there in some core and contributed modules. Shouldn't that be fixed? Even moving them up into the module level from common.inc message() to t() would be a help in promoting usability and translation.
It is not an error to use message_access(), nor does it introduce translation problems as you tried to suggest. It does introduce useability problems in the sense that it does not provide the specific reasons for some failure.
Goba
Now we know what Carl suggests us and I think that worth some consideration: the access denied text shall be changeable upon call time. Piece of cake: function drupal_access_denied($message = NULL) { if (is_null($message)) { $message = t('You are not authorized to access this page.'); } ... drupal_set_title($message); } This does not break the current translation mechanism and a call to drupal_access_denied(t('You do not have access rights in this area please check with the administrator')) is possible. If this is considered a good idea and we can spot other candidates for a similar change, then maybe that if(is_null( construct could be moved to another function which might be drupal_message. Regards Karoly Negyesi
Carl McDade wrote:
There should be an effort to externalize all english text into default variables. It makes a great step towards true internatiolization. Does not cost anything in terms of performance or matainance. What it does do is make the code that uses hard coded strings open and more resuable.
-function message_access() { - return t('You are not authorized to access this page.'); +function message_access($message = 'You are not authorized to access this page.') { + return t($message); }
I do not see how this helps with translation, internationalization and localization efforts. Could you clarify? I do know the following: 1. Using code like this probably results in PHP making a copy of each string into a variable, and that costs execution resources. 2. Currently all strings that can be translated or localized are wrapped in calls to t(), making such translation and localization fairly straight forward. 3. Drupal has been translated and localized into a bunch of different languages and countries around the world, even some east Asian counties. 4. The choices for what represents the messages to be translated are limited to one of two classes: (1) a natural language, or (2) a symbol. In the case of (2) symbols, the development of the software is equally difficult and clumsy for all developers. I've actually worked on such a commercial project, with good tools, and it was still cumbersome and annoying. In the case of (1), the question becomes which natural language do you choose? No matter which one, some developers will be handicapped somewhat. However, choosing English, as Drupal has, handicaps the fewest developers, as English is widely used. It's not a perfect solution, but I have not seen any better ones. Or if I put on my systems analyst hat, I am led to ask this: What is the real problem you are trying to solve? Sometimes a proposed solution to a perceived problem blinds us to other possibilities. Could you state the larger problem you have encountered for which this is a proposed solution? -- Chris Johnson
participants (7)
-
Boris Mann -
Bèr Kessels -
Carl McDade -
Chris Johnson -
Gabor Hojtsy -
Gerhard Killesreiter -
Negyesi Karoly