hook_robotstxt() versus support to multi-language sites

The implementation of hook_robotstxt() which was made from XML Sitemap is incompatible with the support for web sites with more than one language that I am going to implement.
As the module should use an absolute path for the site map, what is it supposed to use? http://example.com/en/sitemap.xml, or http://example.com/it/sitemap.xml, or http://example.com/es/sitemap.xml?

robotstxt.module makes possible to edit the robots.txt file. As it's not possible for XML Sitemap to guess the right URL to pass in a web site supporting more than one language (especially because to support such web sites it needs to use url()), the module can insert the line he needs manually.

• The locale.module in Drupal 6 allows the administrator user to associate a domain to each language; this means that, i.e., the German content could be associated to a domain like http://example.de, while the French content could be associated to http://fr.example.com. For this reason, and also because it's not possible to use the correct alias of a path without using url(), the only way to support sites with more than one language enabled is to proceed like I reported.
• The use of an entry in the robots.txt is not mandatory, in the site map protocol. The correct way to proceed is to register with the search engine all the domains a Drupal web site is serving.

The module will support multi-domain sites by allowing to set an authentication parameter for each of the domains handled by the same Drupal installation.

There isn't a way to workaround the url() function, and be compatible with languages to which is assigned a domain. If you know how locale.module works, then you should know that too.

The only thing you must do is to add that line using robotstxt.module.

The change on the module has made to support a feature which has been requested, and not because i wanted to break existing web sites.

The changes I have made has been based on requests to support web sites with more languages.

Let us keep it open, and hear the opinion from other people. So far, it has been just a person to debate on this.

hass, I know your opinions are strong, but please be less demanding on others. We are very fortunate to have Kiam actively developing this module. Patches are more helpful than demands.

The use of the placeholders used by t() has been fixed where possible; I am not going to change a !variable with @variable when the placeholder must be replaced by an integer. I gave arguments about what I did, and in all of them I showed to be correct.

He debates about an implementation of a hook that the module is not able to implement in the correct way, when all he had to do is to change the setting of another module, and add a single line of text.

Patches are welcome, but if they are not correct, they will not be applied; when they are correct, it's the person who has the task to change the code to decide how, and when to implement it. I have been said to apply the patch without to debate any further, just because I was making him notice he was wrong in his assumption. I could not even reply him that his patch was not only fixing the issue reported, but also an issue reported in another place, and to which the maintainer already replied that he didn't see any reason to change the code like suggested.

I shall remind him of when he said that the code should use file_scan_directory(), and I made him notice that a callback passed to that function does not receive the name of the directories, so the callback used could not be unlink() because it would not be called for the directories, and therefore it could not delete them; not being able to accept he was not right, he then said that if the function was deleting the first level of a directory content, it should use rm(), forgetting for a moment that the code was not deleting the first level of the content of a directory, but it was deleting also all the sub directories contained until the fifth level.

I can have misunderstood the meaning of the by design status, but all I wanted to do was to close all the outdated reports that were not even updated to the recent releases of the project modules from who opened them. It's surely more polite to set them like fixed, and explaining that they have been set to fixed just to make them close automatically; at least in that case, who opened the issue has still the time to change the status of the report, and add more comments if he has any new evidences of what he is talking of.
That is exactly what happened when he saw an issue of his suddenly become fixed; if I would not have changed the status of the issue, he would have forgotten of the report he made ages ago.

In all these debates, I always had to give prove I was correct; I had to show he was not correct in his affirmations, including the one about a critical task being able to block the creation of an official release. It has not been him to give prove he was correct, because when he had to do that he stopped to debate.

Does he care of the time he made me waste in debates were I was correct in my assumptions? The comments are there for all of you to see; you can judge for yourselves, if really file_scan_directory() passes the name of the directories to the callback given it like argument, when it is called to recursively scan the content of a directory.

I want to see what you would have done when you find somebody that open issues basing on the wrong assumption, you correct him, but he keeps to think to be correct even when you prove he is wrong; for sure, when you see another comment by him you think holy smokes, he is back.
If at the beginning you explain him why what he asks cannot be done, at the end you don't give him an explanation as detailed as the first time, and just say what it's strictly necessary.

At the end it becomes like that person who kept to say help, help... there is a fire then it was not true, and he is not believed when there is really a fire.
All the times he opens an issue, it's just him to give his interpretation; there is nobody else that confirm it's true what he is saying (and there could not be anybody else confirming what he is saying, when he is saying something not exact), and he pretends the others do something just because he says that.

I really feel like the poor mortal that is at the presence of the deux ex machina came down from the sky to resolve our issues; don't even try to ask him, because he doesn't ask, he gives orders.

From this moment, I will not reply to his comments. I will use my time to complete the task I took to change XML Sitemap, and create the first official release for the Drupal 6 branch.
I am sorry if he will keep to mess with the issue queue, and for the confusion this will generate in who reads the report issue trying to find a solution to a problem he has. I cannot keep to reply to a person who doesn't understand what the others tell him.

Nobody gave a feedback, so I guess they are fine with the project modules not supporting hook_robotstxt().

I am setting the report like fixed, as there is not action to be taken, in this case.

I have already replied in the first comments.
As there is nobody else asking for this feature, the code is not being changed from how it is now.

@hass: I think you should not reopen this bug unless you come up with a working patch adding the behaviour you need. Kiam@avpnet.org does a lot of work for xmlsitemap and you should respect his decission.

Kiam@avpnet.org thanks for your work.

I have to agree with jandd and Kiam: unless you bring up a workable solution for this to work I really don't see why you have to be so stubborn.
Be more helpful and less demanding ;)

Cheers