Wikipedia talk:Manual of Style/Archive 51

Archive 45

←

Archive 49

Archive 50

Archive 51

Archive 52

Archive 53

→

Archive 55

Directions in French or English?

Captain scarlet claims that "Périphérique Intérieur" rather than "Périphérique inner" should be used - for instance on [1] - because that is the "official name". However, we don't use French for directions like sud; we translate as south. Is there any reason not to translate "Intérieur"? --SPUI (T - C) 12:25, 30 June 2006 (UTC)

I agree with CS, the translation is wrong (adjective should go before noun in English barring rare exceptions or for pomposity) and is anyway uncalled for. And I would keep "sud" as "sud" if it were part of, say, the name of a station. PizzaMargherita 14:01, 3 July 2006 (UTC)

I would say it should be either "Périphérique Intérieur" or "Inner Ring Road". One should not mix translated and non-translated terms. −Woodstone 14:23, 3 July 2006 (UTC)

This is in directions - like "the ramp merges with A13 south" or "the ramp merges with Périphérique inner". Inner is sometimes used as a direction like north and south in the U.S. --SPUI (T - C) 15:37, 3 July 2006 (UTC)

A direction? How? You can say "drive north", but can you say "drive inner"? Anyway, here "Périphérique Intérieur" is the official name. Partial translations are ugly and nonsensical and should be avoided. Shinobu 16:56, 13 July 2006 (UTC)

If used as a direction I could imagine it to mean "clockwise". For a ring road "north" etc have no meaning. The only directions are clockwise (driving right on the inside), or anticlockwise (outside). −Woodstone

The Naming Conflicts guideline, while not strictly applying, has this:

Where a name includes geographical directions such as North, East, South or West (in a local language), the full name should be translated into English: hence East Timor, not Timor-Leste; South Ossetia, not Yuzhnaya Osetiya; West Java, not Jawa Barat.

which seems a fair guide to apply in this case. At least in the case of road directions it would seem most helpful to use the direction in English (that may depend on whether the two directions of the Périphérique are correctly considered as one road or two; but as far as I know it's considered as one road, and the directions are simply directions); so it should be "Périphérique clockwise".

As for "Périphérique" or "ring road", it depends which is most commonly used, in English, of that particular road. In my experience, in the case of the Paris road, it is usually called the Périphérique, which our article naming seems to support (Périphérique (Paris) not Paris ring road; but I don't think that "Périphérique Intérieur" has entered the English language in the same way as "Périphérique" has. (For the ring road of any other French city, it should probably be 'ring road'.)

I've never heard "inner" used as a direction in UK English, so it's probably best avoided in favour of "clockwise", which I think is recognised worldwide. TSP 20:39, 13 July 2006 (UTC)

I still think P.que inner sounds very odd. If P.que is properly ingrained in the English language, we could use Inner P.que. As for the article, it uses a mish-mash of French and English terms, and it is generally very confusing. Shinobu 23:45, 13 July 2006 (UTC)

Percentage signs

In the Johannesburg article, there are dozens of percentages which are given with a space between the number and the percentage sign. This means that something like 53 % is sometimes split over two lines, with the % sign being orphaned onto the second line. Perhaps worth adding a note to the manual of style about no spaces before % signs, similar to the one about colons? --Ott2 17:19, 2 July 2006 (UTC)

It part of the SI standard to leave a space between a number and a percent sign. If you like, you can make it a non-breaking space by entering  . −Woodstone 19:16, 2 July 2006 (UTC)

This does not mean it is a good idea or that it should be standard format on Wikipedia. The non-SI style is vastly more common. —Centrx→talk • 19:39, 2 July 2006 (UTC)

I don't have a strong preference either way, but perhaps it would be worthwhile mentioning this in the manual of style. --Ott2 13:33, 3 July 2006 (UTC)

See also Wikipedia talk:Manual of Style (dates and numbers)#Proposal for section Percentages. This proposal is about a different matter, but at the moment, it looks as though we may include both examples of "12%" and "12 %", in order to cleanly distinguish the proposal from this separate matter. —Centrx→talk • 00:36, 5 July 2006 (UTC)

Also see Wikipedia_talk:Manual of Style (dates_and_numbers)/archive13#Percent symbol with space.3F for an earlier, inconclusive discussion. This is only an issue because someone did use a bot to change all the "45 percent" occurrences to "45 %" in the article (see [2]), which is exactly the problem outlined in the discussion. I don't want to see bot-of-the-week flip this from state to state! --Ott2 16:15, 7 July 2006 (UTC)

If the breaking across lines is an issue use a non-breaking space like this 53 % Rich Farmbrough 09:16 6 August 2006 (GMT).

There's another point: professional printing uses narrow spaces, less than the n-size of word prcessing. This can be imitated with modern wordprocessors, but it's natural to a printer. To see examples of their use to deal with problems such as this, see any old edition of the US GPO style manual. DGG 08:25, 18 September 2006 (UTC)

missing commas

Could a English punctuation expert write a section for this manual on the use of commas? I do Wiki copyedit work and I find most of the changes I make involve missing commas. Commonsense guidance on the usage of commas by Wiki authors might help in the writing and reading of articles, without so much copyedit additions of commas, as I and probably others do. Thanks Hmains 23:40, 4 July 2006 (UTC)

This is, to some extent, a matter of personal style. I am guilty of "rhetorical punctuation" --where a comma means a short pause in speaking, and use them, whenever, I think that natural. Editors remove them, if they can. (I have deliberately added some in the preceding sentence.) DGG 08:25, 18 September 2006 (UTC)

Image sizes

In the article Pac-Man, I think the arcade screenshots would be less-than-useful in anything but their original size of 224x288px. They couldn't be clearly read, and one would probably end up clicking on a bunch of them to see them full-size. However, this size is larger than the default thumbnail width. I propose that we establish the following image size guidelines:

• If the pixelation of an image is important, and its full width is less than 400px, it should be displayed full size.
• All other images outside tables, except inline icons, should be thumbnails.
• The images in a table row should not have a combined width of more than 550px (400px if there is substantial text in the row, 300px for floating tables such as infoboxes).

_SeahenNeonMerlin 15:53, 6 July 2006 (UTC)

So... what's the problem with making the user click the images to see them full-size? I thought that was the whole purpose of scaling down images that would otherwise be too big to display. EVula 17:38, 6 July 2006 (UTC)

No. The purpose of scaling down images is to make sure that they don't intrude in the text to make it more tedious to read and don't extend beyond the size of the browser window or paper (when printed).

Having thumbnails that are indiscernible is useless - in those cases a link is used. (Often a larger picture is used if that doesn't intrude on the text too much - but beware! You can't know the relative size available to the picture and what might appear perfectly okay to you might be problematically large for someone else.)

That said, I tried the main screenshot from Pac-man on for thumb size and it fitted. So unless the picture is really indiscernible or appears corrupted at thumb size, I think we should use thumbnails. Which strikes me as a good general rule too. Shinobu 12:41, 7 July 2006 (UTC)

Clicking is inconvenient because it means either opening (yet) another browser window or tab, or else moving away from the article and having to reload it. NeonMerlin 19:26, 20 July 2006 (UTC)

But having size-fixed images even more so. Not everyone lives in a world where the original size is just a small bit of their browser window. How about people who are using a mobile device? Or about people who don't open their browser full-screen because they've got work to do in other windows that they want to be able to keep an eye on? How about people who just want to compare two webpages side by side? There is a very good reason that users can configure the "thumb" size. If you fix the size this ability is lost.

There are very few images for which pixelation is a real issue. Even for the pac-man images pixelation isn't an issue. Granted, you don't see the full detail, but the images are still discernable and if the reader wants to see more detail, he can always click on the image. *click* *look at the image* *back button* Not as laborious as you make it seem.

The problem with the rule you're proposing is that it specifies pixel sizes, and you just don't know what a pixel is. Ever. Not even if you use the W3C's convoluted definition (which most popular brosers ignore anyway). You don't even know what a centimeter is, for that matter, as long as you don't know the size of the output device. Shinobu 15:00, 6 August 2006 (UTC)

I think the guideline should just say use a thumbnail at the default size, unless there's a good editorial reason (supported by consensus if necessary) to override the user's preference. For some specific pics it does make sense to set an exact pixel size; in the Pac-man article I'd say the image is too big and a thumbnail would be fine. Sometimes I remove specific pixel sizes when they seem done for "promotional" reasons, but I'd leave the Pac-man one up to the article editors. Phr (talk) 11:18, 9 August 2006 (UTC)

Thumbnails can be deliberately designed, manually, to simplify the illustration so it shows the salient points. The various icon sizes in some computer programs are an example. DGG 08:25, 18 September 2006 (UTC)

Empty sections

Is there guidance anywhere about adding empty sections to an article for consistency with some project template? I don't think a section should be added unless there is content for the section, but I couldn't find any mention. older ≠ wiser 16:13, 8 July 2006 (UTC)

Well, it's probably fine to have sections temporarily empty when an article is being actively worked on, but they certainly shouldn't exist in a more finished product. (One obvious subtlety would be whether a section that contains no text in its own body, but only a group of sub-sections—an extra heading grouping some related sub-headings, in other words—counts as "empty" here.) Kirill Lokshin 16:17, 8 July 2006 (UTC)

I wouldn't count that as empty. I agree that empty sections should not exist. If they are in the midst of being worked on they can easily be hidden in "<!-- -->"s. --Jimp 08:28, 19 July 2006 (UTC)