Various string issues

Patch attached.

New patch with a small change.

Thanks for the look over and the patch! Some of these changes are definitely good, a few not so much. I'll get around to give it a closer look soon.

What do you think is "not so good"? I don't see anything... this are all 100% correct changes.

1. Well, for one I'd prefer \'*\' to become "*" instead of '*'.
2. I'm also not sure about lower-casing the "Icons" of the module's name, seeing as I believe it is a proper noun. I'll have to look up in my Oxford for that one.
3. And then there's the "For more information" paragraph, where 1) you've removed "please", and 2) I need to move the i18n handbook page to a languageicons one so it can link to that. :) (Speaking of it, I should probably make a task issue for this...)

By the way, since we're dealing with the strings and I have your attention, do you have any suggestion for a better (or perhaps re-)phrasing of "Link types to add language icons." - the #description for the "Add language icons" fieldset. Perhaps just appending a "to" would be enough, but that sounds a bit clumsy to me. "Link types for adding language icons to."? :/

ps. Btw, t('To enable multilingual support for specific content types go to !configure_content_types.', array('!configure_content_types' => l(t('configure content types'), 'admin/content/types'))) could work, as the 'configure content types' text isn't context dependent - it's the (static) name of a menu or option item. I have no strong feelings either way, just thought that I'd note that the old way wasn't necessarily wrong. :)

#2. Show me only one module name in core that have this upper case. English don't have much upper case in sentences.

#3. I took this sentence over from core. If you think this is wrong we have ~100 wrong strings in core - I expect core is correct. Aside the same string is used in i18n modules and this module reuse this string. Please keep in sync. I have also fixed the currently broken link. Not sure where it should link to if not i18n pages. Feel free to change it if you have an extra handbook page, but don't change the wording to keep in sync with core, please.

ps: Using l() not not ok in translatable strings. See the API docu of t() at http://api.drupal.org/api/function/t/6 and jump to "Here is an example of incorrect usage of t()". The old way was wrong as it does not allow a translator to understand the sentence if he only read the sentence in l10n_server or poedit. Next coder.module version will complain on this as tooo many people ignore this documentation.

Take my corrections as is, please. They are all correct and there is no need to do any changes.

Re 2: It is not a sentence, it is a name, a proper noun. The core modules aren't proper nouns as they're not stand-alone modules, but part of what is "Drupal" (or Drupal core to "insiders"). Most (almost all, IME) other contrib projects use proper noun capitalisation, not sentence capitalisation.

Re 3: I really doubt core mentions the Internationalization module anywhere... And even if it did, Language Icons (not "Language icons") is not one of the I18n modules anymore, so the documentation doesn't belong there - it'll just clutter things both for people looking for information on Language Icons and on the Internationalization modules. See #320060: Move Language Icons documentation from I18n handbook.

Re "ps": The case of the former code of the module and that in the documentation isn't completely comparable. As said, I have no strong feelings either way and do and did plan to commit your change. Please read and understand my comments before replying to them. Thank you.

I also noticed that your patch introduced some (admittedly minor) code style breakage (=>'http://drupal.org/node/133977') which I didn't catch in my update earlier.

And I'd also like to get "Link types to add language icons." fixed with this update, as it doesn't make sense grammatically.

#ps: We should never use l() in strings as you cannot see the intention of the sentence or words that come.

To enable multilingual support for specific content types go to !configure_content_types. is a context sensitive bug. If the sentence keeps is as - translators are not able to understand what the placeholder !configure_content_types. means. In this case it uses the same words like the real string, but this is not the normal case and it could use other words. Additional the translators have no chance to translate the string configure content types correctly in the context of the main sentence. Read this http://drupal.org/node/311883#comment-1024509 and also take a look to core and learn, please. Keep in mind you cannot say for sure this is "static" in all languages of this world - it may work for you and me, but may not for other exotic languages.

I have done string and code style overhauls with very big patches of many modules like views, cck, i18n, fckeditor, panels, og, project, Wysiwyg API, and others. I think I know very well what I'm doing, but I will not fight for #1 at all and not much for #2.

You just spent 3/4's of your last comment arguing a point I said I wasn't arguing about (and only spent 1/5th of my last comment poking at). I know you're overly touchy about your patches, but please, I'm not attacking you personally, and I am glad you're taking the time to look over the code and fix stuff like this - and most of your patch was good too, as I said up front to begin with. You're really blowing this way up, and if this is how you're going to act all the time, I must admit I'd rather not have you work on anything I'm involved with. I just don't have the time nor energy to work with people who do not appear to even try to listen, read, understand what I'm writing, nor actually respond to my questions.

Well, if you wouldn't postphone often my work by a year or so - to a next release (like the pathauto patch), but I'm the only active translator working on modules you co-maintain - I wouldn't be so touchy. If nobody cares about translation except me - I waste my time with translation of deprecated strings and you may know how time consuming the translation job is. Getting strings stable for more then 2 months is a passion of me. Sorry for being touchy.

@Hass:
as Freso has behaved in the same manner (=stealing people's time while nothing is committed) as here with my patch (#300307: Add glossy flag theme) i really was thinking about just forking this module and moving on. However, out of the void a so-called "language interface" module has appeared (ggrr code duplication).. What do you think about this? Fork, improve languageinterface, wait for Freso to get out of his puschen?

@eMPee584:
If you'd like to submit your patch for #300307: Add glossy flag theme at its proper issue, #319966: Add flag icon theme selector I'd be happy to review it. I actually had plans of doing this myself, but haven't yet had time. (Due to work and other commitments.) Please don't poison irrelevant issues with this. Thank you.

Also, if you read this issue, I have actually asked hass (and everyone else, but so far only hass and I have been active in this issue) about how to approach certain problems within the scope of this issue. He, however, has not yet answered any of these questions. (But he has gone to lengths defending approaches I have said I was alright with.) And that is the status of this issue and this patch, awaiting feedback. I'll repeat the most pertinent problem here:

[...], do you have any suggestion for a better (or perhaps re-)phrasing of "Link types to add language icons." - the #description for the "Add language icons" fieldset. Perhaps just appending a "to" would be enough, but that sounds a bit clumsy to me. "Link types for adding language icons to."? :/

I'd be happy to commit a patch where all issues were resolved, and I think the above question is what remains for me to do the last finishing touches on the patch, prior to committing it. But I will not commit an almost-there patch for this, as I have done a few times with Pathauto, where I knew development was on-going (as I or greggles were doing it), as I'm afraid the interest will simply vaporise and the issue will be allowed to live on, unnoticed.

Dear Freso,
you may think you have created this module, thus you are the sole owner of it and do have full jurisdiction and power over it until you either die, or hand it over to the next maintainer. This is not how free/open source software works!!
In this (our) world of digital freedom, everyone scratches his own itch. If there's a problem with the code of other people, you can fix and adapt it for your own means. In a non-commercial context, if you really take the time to polish up your hacks until they are ready for other people's eyes, then create patches and submit them to the project the code belongs to this is to be appreciated as a gift (because it really is: in todays world, time IS money).

So if someone who has probably as much no time as you, maybe even less, is taking that time to implement/fix something you haven't done yet it is not a wise approach to demand of them to adapt to your rules and structure of thinking. Instead it is much more helpful to just step forward and help to make better code move in, whoever committed it (bad/wrong/overly complex patches aside). Committing indisputable fixes (which thousands of non-programmers may subconsciously be waiting on!) one at a time also has been made possible thanks to the latest third millennium technology.

Your way of trying to make people do much more than they already altruistically did when it wouldn't lead to better code and, if that does not happen, drop/ignore the other person's work because they don't (= do not want or have the time to) adapt to your scheme of thinking appears to me as a very counterproductive way of handling drupal module maintainership. I had a much more pleasant experience f.e. with #316295: implement hooks to replace page/block titles, font/style preview, coder style, unicode handling.

wow freso, you really care about OPEN source and your users.
hass have you looked at the languageinterface thing? it is full of LQ code but i'm sending in a patch...

My latest above patch in #2 is correct and only needs to be committed as is and therefore code don't need work.

I don't like to re-read all above and don't like to waste more time on this module. I will only do a translation update *after* the translatable strings bugs are fixed and not for the buggy strings.