"Brion Vibber" brion@wikimedia.org wrote in message news:4A6DC653.9010003@wikimedia.org...
On 7/27/09 6:05 AM, Mark Clements (HappyDog) wrote:
As long as one requires files have explicit type suffixes (e.g. ".jpg", ".svg", etc), one can use the allowed list to determine what file names to translate without generating conflicts. I believe all Wikimedia sites require such suffixes, but Mediawiki can be configured to remove that requirement which would need to be considered for a general application (i.e. what to do if the configuration allows separate files named "Foo_jpg" and "Foo.jpg")
How about making the type a prefix?
Really there's no reason to expose the file type at all at this level; it's an implementation detail which shouldn't be forced onto the on-wiki identifier for a media item.
This suggestion was to solve the problem of serving html documents that appear to have a non-html file extension (e.g. page names which end .jpg). This would provide a one-to-one mapping that is more sensible (imho) than replacing the final period with another character (underscore was suggested).
There is a separate issue of whether this information should be removed altogether, which in theory is a good idea, but leads to a practical problem of naming conflicts which has not yet been addressed to my knowledge (e.g. when "File:Foo.jpg" and "File:Foo.gif" both exist). If that could be resolved then yes, the file's type information would not be required (either as a file extension, or elsewhere). In this case though, my second suggstion ("File:Video:Foo", "File:Image:Bar") might be useful, as we probably still want to know what type of file we are embedding, even if we don't need to know the exact file format.
In the absence of a solution to the second problem, and in light of the fact that solutions to the first issue are currently being considered, I think my original suggestion is quite relevant, and has the added bonus of still being useful if/when the second problem is solved.
- Mark Clements (HappyDog)