String clean up

The WARNING is something that comes from the hook_token_list implementation, so I'm not sure how you can clean it up. Otherwise - sounds great to me.

going into some kind of global registry? Ie., used by token in places outside the realm of pathauto?

That's correct - it's a global listing.

Should I merge #264319: Clean up pathauto_help() with this patch?

As mentioned on IRC, Pathauto current states the following when choosing a default update action in the admin:

"What should pathauto do when updating an existing content item which already has an alias?"

It's nitpicking, but I really thing this should just say:

"What should pathauto do when updating an existing item which already has an alias?"

As "content items" in Drupal refer to node instances, and this setting also applies to users, taxonomy, etc..

#6 is a bad patch.

Example if something that is absolutely UNSUPPORTED in POTX. You should make separate lines with t() and move the <p> outside. You editor have good line break support. Don't do any line breaks inside t().

+      $output = t(
+        '<p>Provides a mechanism for modules to automatically generate aliases for the content they manage.</p>'
+        .'<h2>Settings</h2>'
+        .'<p>The <strong>Maximum Alias Length</strong> and <strong>Maximum component length</strong> values'
+        .'default to 100 and have a limit of 128 from pathauto. This length is limited by the length of the dst'
+        .'column of the url_alias database table. The default database schema for this column is 128. If you'
+        .'set a length that is equal to that of the one set in the dst column it will cause problems in situations'
+        .'where the system needs to append additional words to the aliased URL. For example... URLs generated'
+        .'for feeds will have "/feed" added to the end. You should enter a value that is the length of the dst'
+        .'column minus the length of any strings that might get added to the end of the URL. The length of'
+        .'strings that might get added to the end of your URLs depends on which modules you have enabled and'
+        .'on your Pathauto settings. The recommended and default value is 100.</p>'
+        .'<p><strong>Raw Tokens</strong> In Pathauto it is appropriate to use the -raw form of tokens. Paths are'
+        .'sent through a filtering system which ensures that raw user content is filtered. Failure to use -raw'
+        .'tokens can cause problems with the Pathauto punctuation filtering system.</p>'

should become:

'<p>'. t('Provides a mechanism for modules to automatically generate aliases for the content they manage.') .'</p>';
'<h2>'. t('Settings') .'</h2>';
'<p>'. t('The <strong>Maximum Alias Length</strong> and <strong>Maximum component length</strong> values default to 100 and a limit of 128 from pathauto. This length is limited by the length of the dst column of the url_alias database table. The default database schema for this column is 128. If you set a length that is equal to that of the one set in the dst column it will cause problems in situations where the system needs to append additional words to the aliased URL. For example... URLs generated for feeds will have "/feed" added to the end. You should enter a value that is the length of the dst.... ') .'<p>';

"there" should be upper case first.

+  $form['warning'] = array('#value' => '<p>'. t('<strong>Note:</strong> there is no confirmation. Be sure of your action before clicking the "Delete aliases now!" button.<br />You may want to make a backup of the database and/or the url_alias table prior to using this feature.') .'</p>');

Thank you for the period fixes in your patch.

Take the other patch first in #265711: Some UI typos and bugs.

It's not a credit or something like this, it's - i don't understand why you close a case that contains a *valid* patch. The patch above does not contain this strings and therefor the strings I changed in the other case get lost, overseen and forgotten. What is the problem if we have two cases with strings corrections until there is a patch that merges both?

I don't know why this typos need to wait for a 2.x branch. It's ok to fix this in 1.1.

If it will be tagged, but today it is not tagged and therefor we are able to commit patches that do not need any work (my patch is RTBC) - the above not.

We are talking here about ~10 string changes in a translation file with 170 strings. It's no - really - no issue to fix and translate them before a 1.1 release. Less then 5% changes and 4% only need caps changes that should already exist in all translations. I don't understand why you don't like to get this in earlier. We are not breaking anything as we are updating translations before the release. Aside this is how the CVS system works for ages... not for future but for past.

They are okay, but it's easier to navigate patches having been made using the -p argument to [cvs ]diff. See the handbook page I sent you to, I'm pretty sure it tells about it. (Or perhaps it's one of the other patch pages... ? Hm.)

Patches should not build with -p. Your patch is really worse. If i try to apply this i need to tell explise first where to apply as you removed the path in the patch. This is wrong. Read this http://drupal.org/patch/create

New patch attached:

1. Fixes hook_help
2. Better approach for the format_plural change.
3. Merges the string changes from #265711: Some UI typos and bugs

I'm not sure what you are talking about regarding code changes. The patch in #18 still applies cleanly.

Now the patch with suggestion from #9.

Fresco: Why not committing this to 1.x? It's really the FIRST time ever I saw that a module developer considered translations. This is not wrong... but it's really atypical. And it's not so much changes... we can update the po files *very* quick and easy.

First, this is not the first time that a developer has considered translations - see http://lists.drupal.org/pipermail/translations/2007-August/000445.html

This is a clear regression, and I don't want to do this. 6.x-1.1 will most likely be the last 6.x-1.x release, with development focus shifting to 6.x-2.x as soon as it is released. If you want these strings to be fixed, go help with the 6.x-1.1 blockers so that we may start 6.x-2.x development sooner.

@hass - Please stop disagreeing on this point. Freso has provided a logical argument for doing these changes in 6.x-2.x and I support his decision. So, it's decided. Arguing is a waste of everyone's time. We've already branched the code for 6.x-2.x (hence it is in the version dropdown) so this can now be committed. It just needs a review now, but arguing about versions is a waste of time that reduces the time left to review the patch.

I just reviewed the code for the minor typos I reported in a duplicate issue. They have all been taken care of.

Thanks for redirecting me.

Looks good to me.