The XSL strings should be translated

Instead of generating the entire file contents in code, here's my inital solution in 6.x-2.x:

function xmlsitemap_output_xsl() {
  module_load_include('inc', 'xmlsitemap');
  drupal_set_header('Content-type: application/xml; charset=utf-8');
  $module_path = drupal_get_path('module', 'xmlsitemap');

  $replacements = array(
    'Sitemap file' => t('Sitemap file'),
    'Generated by the Drupal XML sitemap module.' => t('Generated by the <a href="@link-xmlsitemap">Drupal XML sitemap module</a> @version.', array('@link-xmlsitemap' => 'http://drupal.org/project/xmlsitemap', '@version' => _xmlsitemap_get_version())),
    'Number of sitemaps in this index' => t('Number of sitemaps in this index'),
    'Click on the table headers to change sorting.' => t('Click on the table headers to change sorting.'),
    'Sitemap URL' => t('Sitemap URL'),
    'Last modification date' => t('Last modification date'),
    'Number of URLs in this sitemap' => t('Number of URLs in this sitemap'),
    'URL location' => t('URL location'),
    'Change frequency' => t('Change frequency'),
    'Priority' => t('Priority'),
    '[xsl-css]' => base_path() . $module_path . '/xsl/xmlsitemap.xsl.css',
    '[xsl-js]' => base_path() . $module_path . '/xsl/xmlsitemap.xsl.js',
  );

  $xsl_content = file_get_contents($module_path . '/xsl/xmlsitemap.xsl');
  $xsl_content = str_replace(array_keys($replacements), $replacements, $xsl_content);
  echo $xsl_content;
}

Replaces all the strings that need translation, so it works.

I guess I don't have a preference. strtr makes more sense. Some comment from back in 2004 suggests that str_replace is faster (http://us3.php.net/manual/en/function.strtr.php#48095), but again, that's from 2004. Now that you've pointed it out, my neurotic side wants to benchmark compare them. Thanks Kiam. :)

Using ab -n 500 http://mysql.drupal6dev.local/sitemap.xsl with caching disabled.

Using str_replace():

Requests per second:    8.16 [#/sec] (mean)
Time per request:       122.540 [ms] (mean)
Time per request:       122.540 [ms] (mean, across all concurrent requests)
Transfer rate:          38.42 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:   118  122   4.0    121     154
Waiting:       85  118   6.4    117     148
Total:        118  122   4.0    121     154

Using strtr():

Requests per second:    7.56 [#/sec] (mean)
Time per request:       132.313 [ms] (mean)
Time per request:       132.313 [ms] (mean, across all concurrent requests)
Transfer rate:          35.58 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       1
Processing:   127  132   5.5    131     193
Waiting:      111  128   6.9    126     193
Total:        127  132   5.5    131     193

str_replace wins by just under 10 ms. :)

Yep, I know it's used in t(). I guess a 10ms difference isn't really reason enough to prefer str_replace over strtr considering that in most cases this file will be cached and then the speed difference won't even matter. The example you're referring to is str_replace will make replacements in things that have already been replaced, which won't and doesn't happen in our set of strings but could easily happen with the enormous amount of strings that get passed through t(), so that doesn't really matter either. I'll probably change this to strtr anyway, just for simplicity's sake. And it looks nicer.

Suprisingly, I'm actually using Linux Mint/Ubuntu 8.10. I just like using the usual Mac .local domain so I have set up all my localhost domains with it in /etc/hosts. I'm tricky like that. :)

Considering this has been fully implemented in 6.x-2.x, moving back down to 6.x-1.x for consideration.

If anything I don't think making the XSL interchangeable/alterable is a high priority. I am strongly against the approach in #16 because it reminds me of custom_url_rewrite_outbound which were bastardization functions when there should have been proper Drupal hooks. If down the road two other modules want to implement it, they're screwed because only one can 'have' the custom function. Nevermind the problems if both modules declare the function we get a PHP error. So if we want to do it, here's a couple of options I think should be used (at least in the 6.x-2.x branch).

1. If clean URLs are enabled, the user can put their own sitemap.xsl file in the Drupal root directory. This will override the hook_menu() path of 'sitemap.xsl' (think robotstxt module). This doesn't require us to do anything.

2. A module can override the hook_menu() path for 'sitemap.xsl' by using hook_menu_alter():

function mymodule_menu_alter() {
  $items['sitemap.xsl']['page callback'] = 'mymodule_output_custom_xsl';
  $items['sitemap.xsl']['file path'] = drupal_get_path('module', 'mymodule');
}

This function also doesn't require us to do anything.

3. We make a new variable with the path to the XSL file to be read:

function xmlsitemap_output_xsl() {
  $module_path = drupal_get_path('module', 'xmlsitemap');
  $xsl_file = variable_get('xmlsitemap_xsl_file', $module_path . '/xsl/xmlsitemap.xsl');
  $xsl_content = file_get_contents($xsl_file);
  // Do the XSL processing and output
  ...
}

4. Add an hook_xmlsitemap_xsl_alter() so that other modules can alter the XSL before strtr is run:

function xmlsitemap_output_xsl() {
  $module_path = drupal_get_path('module', 'xmlsitemap');
  $xsl_content = file_get_contents($module_path . '/xsl/xmlsitemap.xsl');
  // Allow other modules to alter the XSL.
  drupal_alter('xmlsitemap_xsl', $xsl_content);
  // Do the XSL processing and output
  ...
}

This option they can change certain strings, change the whole darn file, whatever they want.

In summary, I probably prefer #4 as it's the most Drupal thing to do, allows changes small and large. I'm still not decided yet though.

EDIT: I had combined #3 and #4 into #4. I corrected #4.

I backported the basic dynamic generation of the file from the 2.x version of the module. This also fixes if the module isn't located exactly at sites/all/modules/xmlsitemap.
http://drupal.org/cvs?commit=321736