User talk:Verdy p

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Recreating the talk pages (because this was forgotten when the user account was renamed). So there's no talk page history here! Look at "User talk:Verdy_P" if you want to control the history of previous discussions with me... verdy_p (talk) 07:24, 3 July 2008 (UTC)


Please visit my main talk page on French Wikipedia fr:Discussion Utilisateur:verdy_p. Thanks. verdy_p 17:51, 8 November 2006 (UTC)

Contents

Exact Gregorian date formulas[edit]

A few date templates are special and filled automatically by the MediaWiki software (they are referenced internally by templates below whose name start by CURRENT), using the current UTC date and time (in the Gregorian calendar) as set on the Wikipedia server:

  • {{CURRENTYEAR}}, current value: 2014, includes all four digits.
  • {{CURRENTMONTH}}, current value: 09, two digits (includes leading zero).
  • {{CURRENTDAY}}, current value: 2, two digits (includes leading zero).
  • {{CURRENTTIME}}, current value: 12:55, four digits (format: hh:mm).
  • {{CURRENTMONTHABBREV}}, current value: "Sep", 3 letter abbr. for the current month.

From those values, we can compute the following:

  • {{CURRENTCENTURY}}, current value: 21, no extra leading zero.
  • {{CURRENTYEARCC}}, current value: 20, no extra leading zero.
  • {{CURRENTYEARYY}}, current value: 14, no extra leading zero.
  • {{IsLeapYear}}, current value: 0, no extra leading zero.
  • {{CURRENTMONTHNAME}}, current value: "September".
  • {{CURRENTMONTHDAYS}}, current value: "30".
  • {{CURRENTJULIANDAY}}, current value: 2456903.0382523, no extra leading zero.
  • {{CURRENTWEEKDAY}}, current value: 1, no extra leading zero.
  • {{CURRENTWEEKDAYNAME}}, current value: "Tuesday".
  • {{CURRENTWEEKDAYABBREV}}, current value: "Tue".
  • {{CURRENTISOYEAR}}, current value: 2014, no extra leading zero.
  • {{CURRENTHOUR}}, current value: 12, two digits (between 00 and 23).
  • {{CURRENTMINUTE}}, current value: 12:55, two digits (between 00 and 59).
  • {{CURRENTINTERNETTIME}}, current value: @579, three digits (between 000 and 999).

The Template:JULIANDAY is the base computing template that allows making various calendar computations. From this computed value, it is possible to get back to the date components, for example:

  • {{JULIANDAY.YEAR|{{CURRENTJULIANDAY}}}}, current value: 2014.
  • {{JULIANDAY.MONTH|{{CURRENTJULIANDAY}}}}, current value: 9.
  • {{JULIANDAY.DAY|{{CURRENTJULIANDAY}}}}, current value: 2.
  • {{JULIANDAY.HOUR|{{CURRENTJULIANDAY}}}}, current value: 12.
  • {{JULIANDAY.MINUTE|{{CURRENTJULIANDAY}}}}, current value: 55.
  • {{JULIANDAY.SECOND|{{CURRENTJULIANDAY}}}}, current value: 04.

These templates are optimized for speed but do not compromize exactitude of results. They work on the whole UTC calendar since 1 January -4800 UTC (4801 BC):

  • for all dates in the Gregorian calendar
  • in the proleptic Gregorian calendar in the Christian era before 1782 AD,
  • and applying the same proleptic rules for dates in the pre-Christian era (only the year counting uses the continuous UTC counting mode for years), i.e. using year 0 for 1 BC.

integer and floating point[edit]

Hi, Verdy. I'm the guy who got the whole Category:Date math thing going. I've been talking with some of the other guys, like zocky, and we'd like to suggest the possibility of making a distinction:

  • integer-based math (for ordinal dates)
  • floating-point math (for Julian dates)

Can we talk? --Uncle Ed 14:52, 5 May 2006 (UTC)

Is there a distinction between both? Templates using Julian date only use integer arithmetic where appropriate, unless you use decimal values or time. You can't be really correct when computing dates without considering the arithmetic of years which is muchmore complex than what you think, and hasmany caveats.
Now that Juliandays are computed correctly (very simply in fact), most dates can be infered from them. I took lot of time to get the correct julian day calculations, that cover the whole Gregorian calendar and the whole proleptic calendar since epoch (4800 BC). The past templates before that were wrong in many dates, even in the non-proleptic Gregorian calendar since 1782.
I have documented the most complex algorithms (reverse from julian day) in the Julian day article (initially I rewrote wrote them in French Wikipedia, then I translated them back to English).
Due to the complexity of those algorithms, we should keep things simple but still correct, by using the now working and optimized templates.Do you see an error in the templates I made ?
My recent modifications today are handling now obvious calc bugs (results incorrect for some dates), and are generalizing the templates for wider use.
Sincerely, Philippe. verdy_p 15:02, 5 May 2006 (UTC)

Ordinal date[edit]

I reverted a recent change you made, please take a look at it's talk. — xaosflux Talk 00:51, 27 May 2006 (UTC)

Template:JULIANDAY.JULIAN[edit]

Hello, could you please take a look at Template talk:JULIANDAY.JULIAN. Thanks. --5ko 12:34, 19 July 2006 (UTC)


TfD nomination of Template:CURRENTHOUR[edit]

Template:CURRENTHOUR has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for Deletion page. Thank you. 03:30, 8 September 2006 (UTC)

It was not necessary to delete it. It was there for:
* completeness, and for allowing support on other versions of the MediaWiki software without a builtin implementation.
* documentation purpose, allowing to to link related templates that are not built into the software.
The server, when it implements the template natively uses its builtin implementation and the template itself is not used. So the presence of the template has a null cost on pages using it! The deletion did not improve performance of pages using it because they already use the builtin template when supported.
verdy_p 17:46, 8 November 2006 (UTC)
And please use my MAIN user talk page on French Wikipedia. I am rarely connected directly with my account on English Wikipedia, so I did not see your notice...
So remember this: fr:Discussion Utilisateur:verdy_p.

Minor edits[edit]

Please remember to mark your edits as minor when (and only when) they genuinely are minor edits (see Wikipedia:Minor edit). Marking a major change as a minor one (and vice versa) is considered poor etiquette. The rule of thumb is that only an edit that consists solely of spelling corrections, formatting, and minor rearranging of text should be flagged as a 'minor edit'. Thanks! You probably need to change your preferences. Edits summaries would be useful too. I don't for example understand your intentions behind your recent edits associated with Category:Culture of Oceania - I would have expected a discussion at Wikipedia:Categories for discussion before this edit. (I will repost at French wikipedia as per your note on this page) --Golden Wattle talk 22:28, 14 November 2006 (UTC)

Those are really minor edits, without much change (ordering the categories to solve red links, and to group together synonym categories according to naming conventions). This allows finding the related articles through those categories (along several orthogonal search axises).
All of them are in Samoa/Polynesia, and I have sorted some categories relate to culture.
verdy_p 22:32, 14 November 2006 (UTC)
Regarding "Culture of Oceania", it was correct until I found that there was a second category named "Oceanian culture", so I had to merge them... verdy_p 22:33, 14 November 2006 (UTC)
Thanks for the explanation but edit summaries would have been nice and almost certianly appropriate, particularly when it comes to merging categories.--Golden Wattle talk 22:52, 14 November 2006 (UTC)

FA nomination for California Gold Rush[edit]

The California Gold Rush article has been nominated for Featured article status. If you would like to comment on this nomination, please go here to leave your comment. To leave a comment on that page, click the [edit] link to the right of the title California Gold Rush.NorCalHistory 21:06, 2 December 2006 (UTC)

'Flemish' article, or 'Flemish' as disambiguation page + 'Flemish (terminology)'[edit]

Hi. A few months ago you did some drastic editing with respect to languages and dialects, in the article Flemish. Meanwhile the page has of course evolved further. You will see that I weeded out some inaccuracies, but maintained the concept that you had introduced. Last week however, I was in a mean discussion and edit war trying to preserve the article. There is now a proper proposal to move the article, and to make 'Flemish' a straightforward disambiguation page. Please, have a good look into the Talk:Flemish in general before stating your opinion in its 'Requested move' section. Kind regards.
[P.S.: Note that the older history of 'Flemish' is found as the history of for the moment a redirect page 'Flemish (terminology)': see here] — SomeHuman 20 Dec2006 20:41-20:58 (UTC)

Sudden growth of ceb-wp[edit]

Hi there,

I am Bentong Isles, a minor editor here at en-wp. I am the bureaucrat and sole admin of ceb-wp. I appreciate your taking time to bring to our attention the sudden growth in our wp. We thought no one noticed ;)

Before the importation of the articles about the French communes, there were only three "regulars" to ceb-wp: Harvzs; Edgar Godin, a friend of mine who is the associate editor of Bisaya Magasin, the prime literary magazine in our language; and myself. Mr. Godin is an expert on Cebuano literature, being in the field for most of his life, but he always forget to log in before he adds his articles to ceb-wp, so that's why he is credited as an anonymous user. Harvzs is busy uploading translated stubs about Philippine towns. I am in charge of translating the interface and generally popularization efforts of ceb-wp.

The French commune articles were uploaded by myself. The first three thousand articles or so were uploaded using my own account name, then I realize that other users edits are being hidden by that, and they do not have the option of hiding my edits, so I created a bot to do the repetitive tasks for me. The articles are translated from Italian stubs.

I've checked with Wikimedia policies, and correct me if I am wrong, but there is no policy against importation of articles by bot, so I did myself and the ceb-wp community a favor by uploading the files. Ceb-wp does not have a policy on bots too, but during the last few weeks I've sent requests to bot users to have a request filed for their bots to be flagged as bots so as to hide their edits.

On the other hand, the sudden increase of the number of users can be partly attributed by my using the community of Cebuano wikipedians here on the English Wikipedia as base. User:Pinay09 and another Cebuano user whose name escape my memory of the moment are two of those who were originally active here on en-wp (they still are) but have shifted some of their resources to the "upliftment" of ceb-wp. Hopefully they'll stay.

As to the picture of Sheryn Regis which appeared as part of a featured article, I will check with Mark, the user who wrote that article in our wp. AFAIK, the same picture is used on the artists page here at en-wp. Mark is (acording to himself) the online p.r.o. for Regis.

Thanks! And merry Christmas!

--Bentong Isles 07:25, 27 December 2006 (UTC)

It's User:Pinay06 and not 09. Sorry for the mistake. The other user is User:Emperork. --Bentong Isles 07:29, 27 December 2006 (UTC)

move[edit]

I have moved Setting up your browser for Indic scripts to User:verdy_p/vedic. Please move it to Wikibooks or the help: namespace as appropritae. -- RHaworth 10:34, 15 January 2007 (UTC)

I wrote it there because it is referenced directly by the Telugu edition of Wikipedia, at top of its page (look at the message which says "if you can't read Telugu "click here"), and there's no way to change this reference because it is part of the installation of this Wiki (and not in a user-editable part)!
You should not have move it ! Please look at the Telugu Wikipedia! verdy_p 10:39, 15 January 2007 (UTC)
I have reverted your immediate move and delete (the immediate delete was really unjustified!) You should have first checked the provided link. verdy_p 10:45, 15 January 2007 (UTC)
Note: the text is minimal, it should relaly contain a link effectively to a more complete article, but until then, we need something with this title. So don't delete it! I can't speak Telugu, so I can't ask to Telugu Wikipedia admins to modify their installation. verdy_p 10:50, 15 January 2007 (UTC)
also I don't like that you move an article which is not for me, into my own namespace. I am not a Telugu Wikipedia admin. verdy_p 10:51, 15 January 2007 (UTC)

If you want me to look at the Telegu Wikipedia, provide a link to it! The article was written by you, where else should I have moved it? -- RHaworth 10:59, 15 January 2007 (UTC)

I have provided the link! Please read... verdy_p 11:00, 15 January 2007 (UTC)

The link at the top of each page in the Telegu Wikipedia is: a) to te:వికీపీడియా:Setting up your browser for Indic scripts not to the English Wikipedia, b) it is in the వికీపీడియా: namespace not the (Main) namespace of the Telegu Wikipedia. So why do you claim that here it must be in the (Main) namespace? -- RHaworth 11:17, 15 January 2007 (UTC)

Well it was just changed... I can ensure you that I have followed the link that was proposed there just one minute before I dropped the small note; that's exactly when I noted that it was created on the English Wikipedia.
So it's highly probably that the Telugu wiki has been updated to point to its own page (in English), instead of the page that was previously in the English Wikipedia. Look at the creation date: the page was just imported, with a notice asking to Telugu uysers to NOT translate it from English!
So now that the Telugu wiki was updated, you can delete the page on the english Wiki... I see no inconvenience... verdy_p 11:22, 15 January 2007 (UTC)
Conclusion: I have NOT made anything wrong. Only admins on telugu have pointed the incorrect page. Look at the hostory of the Telugu page: the change is noted by someone else, which is an admin there! verdy_p 11:24, 15 January 2007 (UTC)

Template:Rand[edit]

Hi Verdy, I translated your function for the de:WP (see de:Vorlage:Zufallszahl) replacing the MOD function, as de:WP does not have it. I experience some problems in occasionally getting negative numbers witch seems to be a sign overflow to me. Are you aware of any such problems. Thanks --Farino 17:14, 21 January 2007 (UTC)

Yes, I am aware of this problem with the builtin (bogous) mod operator, and that's why I have also used Template:Mod that documents the various critical cases where mod is bogous. If you use Template:Mod, you won't get the sign error! verdy_p 04:39, 2 February 2007 (UTC)
Note that negative overflows when computing the integer additions are expected within this template. This is not a bug. But overflows shuold disappear when computing the final modulo. Unfortunately, the mod operator does not respect the contract, and returns modulo values that may be negative and not of the same sign as its second operand. I've corrected your German adaptation: x mod y can return only values between -y+1 and y-1, but when it is negative, you can add y to get the correct value; if the result is positive adding y will overflow but taking the modulo y will substract y again so you'll get the mathematical modulo expected by this template. verdy_p 04:57, 2 February 2007 (UTC)
Your help was much appreciated. It would have taken me months to sort this out. If I can ever help you with something in the de:WP let me know. --Farino 18:55, 2 February 2007 (UTC)

Image Height/Width only[edit]

Hey - I saw your comment on the main page discussion where you listed your template found here - but I have a few qs if you don't mind.

  • Is this usable on English Wikipedia?
  • Where do you say what the image is?

I appreciate any help you can give!--Daniel()Folsom T|C|U 22:16, 21 January 2007 (UTC)

You can copy it of course (this is permitted by the Wikipedia GFDL licence!). There's an English translation on Commons (named Template:ImageWidth).
Look at the links from this Wiki: fr:Modèle:LargeurImage, or commons:Template:ImageWidth.
It is currently used to display the Picture of the Day here fr:Wikipédia:Image du jour using coherent image sizes.
Note that you don't have to specify the image. The parameters are just the actual image sizes, and the template computes an image width for use within an Image link; you still have to create the image link separately, with the optional alignment parameter, thumb parameter, or description parameter... Look at examples in the French pictures of the day... which is formatted using fr:Modèle:ImageDuJour.
The effect of this template is to apply a maximum size constraint to the image so that it will fit within a symetric Saint-Andrew Cross (similar to the Swiss flag), whose minimum and maximum sizes are specified. In all cases, the returned image width will never be larger than the original image width (if the original image size is too small, it is kept unchanged, to avoid bad-looking growth with fuzy pixels, or visible squares. For scalable SVG images, instead of specifying the original image sizes you may specify any multiple of its natural sizes without problem. For bitmap images, the sizes specified should those of the original image, as seen in its description page...
verdy_p 04:36, 2 February 2007 (UTC)

EUMETSAT[edit]

Do you work there? --Ysangkok 21:41, 22 January 2007 (UTC)

No.... Sorry... Not even for a member meteorological agency. What I included is public data (I cite the references found). verdy_p 04:37, 2 February 2007 (UTC)

Image:Ptolemy_sine_proof.svg (SVG file, nominally 460 × 460 pixels, file size: 2 KB)[edit]

Hi Thanks for doing this - clarity is considerably improved compared to my original diagram. Neil Parker (talk) 18:41, 8 April 2008 (UTC)

French phonology[edit]

I am not convinced that your changes to this article are an improvement. Please add references for the statements you've added. Joeldl (talk) 09:37, 3 May 2008 (UTC)

Let me see if I can't take your edits one by one
  1. You said in an edit summary "There's ample enough references everywhere (just listen French records, TV, radio, music, cinema...)" but these are not references. These are what's called "primary sources" and we generally frown upon using them. In addition, for someone unfamiliar with the French language, they will not illustrate your point. You need secondary resources like linguistics books and articles. Dictionaries can work, though they can be oversimplistic in regards to phonetic attributes.
How can a printed book or article display the phonetic? Audio records are more convinceable than written articles, notably if they are written by non-native French speakers leaving in a non-French speaking country, and citing their own references about old French as spoken in the 19th century. verdy_p (talk) 19:33, 3 May 2008 (UTC)
  1. You added "when this is differenciated, the back vowel is just made longer than the front one but positioned identically." Whether this is true or not it is uncited; you added it between a cited claim and its citation, making it seem as though this was cited.
  2. You added a paragraph about the distinctions between /e/ and /ɛ/. This information is already covered in the article.
No, it was not correctly covered.
Anyway there's another formatting problem: you need more text above the first table to avoid the blank area above (due to the infoboxes on the right. verdy_p (talk) 19:33, 3 May 2008 (UTC)
  1. You added a paragraph about the distinction between /ə/, /œ/ and /ø/. The distinction between /œ/ and /ø/, as well as length allophony, are already covered. The claim that speakers can't see any distinction between schwa and /œ/ is uncited. Also, don't expect to find a reputible source arguing that "schwa is certainly the least understood phoneme by native speakers, because it has very variable realisations." Just because you can't explain the distribution of phones doesn't mean that native speakers don't understand a phoneme. In fact, it's more likely the opposite. The claim that the vowels in "le bœuf" /lə bœf/ or "demi-heure" /dəmjœʁ/ are pronounced identically or swapped is uncited.
I can claim that those three vowels are extremely frequently mixed, with /œ/ being realized either as /ə/ or /ø/. The only real difference betwen the schwa /ə/ and /œ/ is that the former can become completely mute in fast speech and often too in normal speech, or short in slow speech, when the later cannot be mute or abbreviated as it is in fact longer (and should occur only as /œ:/. verdy_p (talk) 19:33, 3 May 2008 (UTC)
Everything else is formatting stuff, which I don't necessarily disagree with (though, really, putting quotes in the syntax of the table doesn't make any difference in its appearance so you needn't go out of your way to change that). My comment on the table wasn't on your choice, it was more on the awkward formatting. I'll fix it for you. — Ƶ§œš¹ [aɪm ˈfɻɛ̃ⁿdˡi] 19:13, 3 May 2008 (UTC)
Which quotes? I see no added quote. verdy_p (talk) 19:33, 3 May 2008 (UTC)
I was referring to quotation marks. So in the table if it said
align=center
and you put
align="center"
it makes no difference on the table. The only reason it seems like I'm undoing it is because I'm either making blind reverts or, as in my most recent edit, working from full reverts and adding information.
I've moved most of the information that you added to the proper sections. They have citation requests on them now. — Ƶ§œš¹ [aɪm ˈfɻɛ̃ⁿdˡi] 19:45, 3 May 2008 (UTC)
OK, but these quotes are nearer from the XML and HTML syntax; it was not to make things less readable.
One of my formatting also wanted to merge table cells that make the same row into a single line, as it is certainly clearer like that to edit than a long vertical list of cells with few characters per line, which is needed only in case of complex formatting where all can't fit clearly on a single line where cell separation is not easy to see.
verdy_p (talk) 19:50, 3 May 2008 (UTC)
If you'd like, go ahead and edit the table with the quote marks and the items in a single line. I'll make an effort not to undo it. You're right about needing more text before the vowel table, I'll see if I can't figure something out. — Ƶ§œš¹ [aɪm ˈfɻɛ̃ⁿdˡi] 19:55, 3 May 2008 (UTC)
I noticed you changed the example from ses to passé. I'm quite surprised of your claim that ses doesn't have a close-mid [e] (you said "open e" in your edit summary, but I believe you mean "close e" as this is how linguists refer to it). The example comes from Fougeron & Smith (1993) which was reprinted in 1999 presumably with no changes. The nice thing about ses was that it was a minimal pair with sait. Can you think of any other minimal pairs between the two? — Ƶ§œš¹ [aɪm ˈfɻɛ̃ⁿdˡi] 20:22, 3 May 2008 (UTC)
The comment was sent when I was correcting it. But it's true the "ses" is not a conclusive word (not even ces which is pronounced identically). It used to be prononced with a closed e (like 'é') but is now most frequently prononced with an open e (like 'è'), and ALWAYS as an open e when there's a liaison (''ses amis : [sɛ_za.mi] but ses parents [se pa.rɑ̃] or more frequently now [sɛ pa.rɑ̃] ...) For this reason, it's best to avoid it in examples and use more definitive words.verdy_p (talk) 20:34, 3 May 2008 (UTC)
I like the table that you've included in regards to vowel length, but I have issue with your use of the stress marker and your claims about stress. As it stands right now, the article contradicts itself and your claims are unsourced. The source may be from 1968 but it's backed up in Anderson (1982) (this is discussed in the talk page). Labeling French words with stress markers is misleading as the stress is only there when the words are uttered in isolation. Otherwise the stress depends on the word's placement in a given phrase or utterance.
No contradiction, and I explained it in the last paragraph (which also explains that the phonological stress is most often marked by a phonetic distinctive tone). It also says something really important in French: stress is MUCH, MUCH less marked than in English, in fact it is most frequently marked by tonality. Anderson speaks about pure phonology (related to meaning), not much about the mapping between phonology and the actual phonetics (which varies a lot according ro regional accents).
I've tried to mix phonology and phonetics, but if you just speak about phonologic stress, you're missing the point that it does not necessarily means a phonetic stress. verdy_p (talk) 00:15, 4 May 2008 (UTC)
Also, can you justify using the dot separator for syllables? It seems unnecessary to me and how you've put it may even be correct in cases with final [ʁ]. — Ƶ§œš¹ [aɪm ˈfɻɛ̃ⁿdˡi] 23:55, 3 May 2008 (UTC)
The dot is standard in IPA for marking syllabic breaks. There's no dot in phonetic, but dots exist in phonology, as they mark how the vocal speech is parsed by auditors. Syllable breaks are either dots (between syllables of the same word), or spaces (between words without liaison), but the connecting lower sign (between words with liaison) joins phonemes from two separate words that create a single phonetic syllable (but no true syllable) where a space would be otherwise written.
All French dictionnaries (Larousse, Robert, Littré, Académie française, as well as American ones) display the phonology using dots separators between phonetic syllables. They don't attempt to note the phonetic due to variable accents, even though they designate this notation as "phonetic". That's why it is given between [square brackets] and not /slashes/. verdy_p (talk) 00:15, 4 May 2008 (UTC)
I've started a discussion at Talk:French phonology. We shouldn't be the only ones to discuss the issue of stress. — Ƶ§œš¹ [aɪm ˈfɻɛ̃ⁿdˡi] 00:32, 4 May 2008 (UTC)
OK, but syllabic separation is part of phonology. You may omit it but this is just for simplified phonology. Syllable breaks play a big role in French, even if they are not most often not realized phonetically in normal speech.
That's why i wanted dots, spaces, and elision marks in the [phonologic] notation but not in the /phonetic/ notation that is NOT unique in French (also not unique in English) due to accents.
In /phonetic/ notation, pauses are marked only when they are realized, and the effective realization of all vowels and consonnants need to be specified, as well as the effective regional accents.
When you use the [phonologic] notation, there's no difference between the regional variants of French, because it is highly standardized (that's why it is prefered in dictionaries): it is generally the same between France, Canada, Belgium, Switzerland and Africa, even if the exact phonetic is different.
In rare cases, the French dictionnaries may exhibit several phonologies (for example with monsieur) but one is generally much more widely used and the other is "antic"; a homographic few words have two phonologies that are described in separate lemmas because they are not synonyms and not necessarily with the same grammatical nature (example: fils can be [fis] and phonetically /fiːs/ or /fis/ if non-final in sentence, meaning "son(s)" in singular or plural, or [fil] and phonetically /fiːl/ in isolation or /fil/ in non final position, meaning "thread(s)" in singular or plural; they should also be distinct phonetically). Here again, the phonology translates the actual meaning and differenciation effectively made in the vocal speech. verdy_p (talk) 00:53, 4 May 2008 (UTC)
You seem to be confused at times about the brackets vs slashes. Slashes are for phonemes. When you're talking about phones (including allophones) brackets are appropriate. Saying that [ʁ] has a wide range of realizations and then listing those with slashes is backwards (also, btw, the phrase "The French rhotic" is used deliberately in place of any symbols to be neutral. — Ƶ§œš¹ [aɪm ˈfɻɛ̃ⁿdˡi] 06:04, 4 May 2008 (UTC)
Well this is the convention used in French books. May be it is reversed in English books... verdy_p (talk) 06:47, 4 May 2008 (UTC)
This is IPA usage. If you're just looking at dictionaries they might have an idiosyncratic system. — Ƶ§œš¹ [aɪm ˈfɻɛ̃ⁿdˡi] 06:50, 4 May 2008 (UTC)
In that case everything is reversed in the English article... and all the phonology notations given for words should be in slashes, not brackets where liaisons and syllable breaks or word separation in sentences makes little sense... Notably because the example words all have several phonetic realizations that depend on accent and context of use and also because the stress marks which are given for the phonology are not realized as stresses by most French speakers. So when you reverted these changes, you should have done it everywhere, not just the few locations that I had changed. verdy_p (talk) 06:55, 4 May 2008 (UTC)
There are a number of things I haven't undone or fixed because I'm waiting for you (or someone) to comment on the stress situation. — Ƶ§œš¹ [aɪm ˈfɻɛ̃ⁿdˡi] 08:22, 4 May 2008 (UTC)
What are you doing? These are fundamentally incorrect:
  • /mɛː.tʁ(ə)/ /ˈbʁaː.v(ə)/the schwa's presence is conditioned (so it shouldn't be in parentheses, the long vowel is a conditioned variant, and the syllable break is unnecessary (French doesn't contrast CVC.V with CV.CV)
Syllables are fundamental in French for its understanding, and correct pronunciation, adaptation of rythm, just like punctuation. The orthography is attempting to match the phonology (with lots of exceptions), but speaking about syllables at the phonetic level is absurd. it is necessarily at the phonologic level. verdy_p (talk) 00:08, 5 May 2008 (UTC)
  • /pwa.ˈɲɛ/, /ʒə fə.ˈʁe/ syllable break shouldn't be there, stress is not phonemic in French.
In that case there can be no stress mark at all at the phonetic level, because it is not marked or realized phonetically as stress but using tone or rythm (alternance of long or short vowels or inclusion of pauses), most of the time. This is highly variable across accents, but what is constant at the phonologic level is the position where it is marked after parsing the language at a syllabic level. It's imposible to predict in French *how* stress will be realized phonetically, or even if it will be realized, but it's just possible to predict *where* it will occur (because this conditions the mutual easier understanding between speakers and autditors of various regions, as they'll determine where words are separated. Note that the last non mute syllable is the most important in all French words, and that's why the accents present at end of words are given stronger importance in French sorting than accent differences at the begining of words). verdy_p (talk) 00:08, 5 May 2008 (UTC)
  • /ˈsœːʁ/ long vowels aren't phonemic in French.
Maybe it's not about slashes brackets. Maybe you don't understand some basic concepts in phonology like a phoneme, allophone, conditioned variant. Also see minimal pair, complementary distribution, and morphophonologyƵ§œš¹ [aɪm ˈfɻɛ̃ⁿdˡi] 17:54, 4 May 2008 (UTC)
Yo uare assuming things, the only disagreement we had was about the convention to use between /pho.no.lo.gic notation/ (where syllables make sense) and [PhoneticRealizations] (where the syllable breaks don't make sense, and even the separation of words, due to the many liaisons that French has): that's because most French books are reversing the slashes or brackets. But I've always said that dictionnaries DON'T display the actual phonetic of words, but concentrate on the phonology, and they note in this notation where the stress is present, where the conditional schwa (or optional phonems) is present between parenthese, and where each syllable is delimited.
And you're wrong at another point: there are contrasting CVC.V with CV.CV in French !!! Notably between radicals and prefixes/suffixes, or with the many compound/agglutinated words that French has (independantly of the reformed orthography that is removing the written hyphen, because it has never been marked vocally). And this gets even more complex when you see that French incorporates words or radicals coming from lots of languages (not just Latin and Greek, but also various Indo-European languages, Arabic, and now more frequently words borrowed from South and East Asian languages). This contrast between CVC.V and CV.CV is part of inderstanding and also conditions the orthography. It also reveals the actual meaning of words and dictionaries are separating *at least* the prefixes/radicals/suffixes, not just at the orthographic entry, but also in the phonetic notation to show how words or each part of the word can be separated (after this, there's free variation posible of tonality, pauses, lengths between the syllables, as long as the last non mute syllable remains marked distinctly, something that is different from the English phonologic stress which is also a phonetic stress. verdy_p (talk) 00:08, 5 May 2008 (UTC)
May be you think that syllable breaks should be part of morpho-phonology. However adding another layer on top of morphology is not productive in French: words have a single phonology, even if they have distinct phonetic realizations; and trying to create an inventory with multiple phonologies mapped from a top-level morphophonology just complicates things, as French will not recognize the lower-level morphology you create, but just the top-level.
You have to understand that French comes from a standardization and unification of lots of regional dialects, and is more recent in the history than English, the phonologic system adopted tries to simplify things and then the orthography was standardized from this systemic phonologic system. Even if regional differences are disappearing now, it remains that there's ample enough variation in actual pronunciation, and trying to match all of them distinctly at the phonologic level makes absolutely no sense.
So remember this: the phonology is normative in French, not the phonetic, and it's the same phonology that is used for giving the meaning of sentences (there is also other semantic information in the variations, that translate the intention or emotion of the speaker, but they are not written orthographically outside basic punctuation, but even the punctation is also largely normalized because French would be quite hard to read and understand without it). verdy_p (talk) 00:22, 5 May 2008 (UTC)
Last note to you Ƶ§œš¹ directly: I do not appreciate your way of participating, when you are appropriating an article about a language you don't even know a bit, and when all you can do is just revert, i.e. destroy, abruptly contributions by others, without even finding any evidence that there's something wrong.
Things are certainly missing or may be explained, but your way of participating here is just destructive, and blocks all cooperation.
Unlike you, I have NOT deleted things made by others, I can improve what I create, others can modify what I do or improve it, but you systematic destruction (even if you are calling this "partial revert", in fact this is wrong you are reverting everything in several steps, forgetting to reinsert even the evident corrections that were made) is unacceptable.
I see that you are doing this for every article speaking about phonetics and phonology, even when they are trying to do something for the many languages you don't know. Your contribution is probably appreciate to help fixing the convention (i.e. technical), but don't remove things about languages you don't know. The English wikipedia is FULL of errors when it presents other languages than English, because it assumes too many things according to the English usage, and if others are doing like you, that cannot even verify what is written in the articles maintained in the other native editions of Wikipedias (where there are lots of others sources, but not restricted to English sources only), then the English Wikipedia will be counterproductive and will be still considered as a source of false information. verdy_p (talk) 01:06, 5 May 2008 (UTC)
French phonology will fundamentally discuss the phonetic attributes of sounds. I can see how the syllable breaks are notable for French because of the ways in which liaison affects the position of consonants. Liaison is a phonological process, meaning that somewhere between the mental construct of a word (given in slashes) and the actual sounds coming out of a speaker's mouth (given in brackets) a phonological process determines the position of consonants. This is my understanding of French phonology that I've gotten from reading about French. You apparantly disagree, so give me an example of a contrast between VC.V vs V.CV
You say "In that case there can be no stress mark at all at the phonetic level..." That's what I've been arguing for. Are we then in agreement?
I'd hardly call what I'm doing destructive. If my way of participating hasn't fostered cooperation, then we've been cooperating in spite of it. Look at how much of your edits I've moved and cleaned up. You've been here long enough to know that Wikipedia relies on sources, not on ethos. As such, you've cited nothing and referred only to dictionaries in the talk pages. the citation requests are there to give you or other editors a chance to cite. It shouldn't take too long to cite them. Maybe you should tell me how much time you need to cite. — Ƶ§œš¹ [aɪm ˈfɻɛ̃ⁿdˡi] 01:33, 5 May 2008 (UTC)

I know that you're supposed to use English on talk pages, but here I'm going to make a brief exception. verdy_p, j'ai vu le résumé suivant d'une de vos modifications:

restoring the deleted note about the palatal nasal. Attested EVERYWHERE (printed or online dictionnaries, also French Wikipedia and Wikiktionary). You don't know French !!

Je crois qu'il est grand temps que vous vous pliiez à la règle du jeu quand un autre contributeur vous demande de justifier vos affirmations, en présentant vos sources. Sur la Wikipédia anglophone, nous tolérons assez mal les affirmations non-sourcées. Vous avez peut-être bien le français pour langue maternelle, mais cela ne vous rend pas pour autant omniscient. Il me semble en particulier que l'affirmation selon laquelle gn ne se prononcerait « encore » [ɲ] que « dans quelques régions » reflète assez mal la réalité. Peut-être ai-je tort là-dessus, mais seule une discussion fondée sur des sources scientifiques, et non sur votre qualité de francophone, le démontrera. En attendant, je vous invite à faire preuve d'un peu plus de respect envers un contributeur qui ne vous demande rien de plus que de faire votre devoir en tant que contributeur, et qui, soit dit en passant, a déjà fait énormément pour améliorer le contenu de la Wikipédia anglophone en matière de langues. Joeldl (talk) 03:19, 5 May 2008 (UTC)

J'ai mentionné les sources: n'importe quel site de news TV ou radio française, ou chanson française montrera à l'auditeur (peut-être pas au lecteur qui cherche encore des références bibliographiques anciennes qui discutent plus de la théorie que de la pratique de la langue) que "gn" n'est pratiquement plus prononcé en France de l'ancienne façon. Tout le monde ou presque prononce [nj], et c'est plutôt les exemples où on prononcerait encore [ɲ] qui sont presque impossibles à trouver et entendre (je me demande bien où on la prononce effectivement, un accent du Sud ? L'accent de Marseille n'est pas la norme la plus courante et tent aussi à s'effacer) ! Je veux bien admettre que cette ancienne prononciation existe encore (puisqu'elle a été attestée dans la littérature ancienne), cependant je ne pense pas qu'il faille laisser faire croire que c'est la prononciation par défaut. Il n'y a aucune différence audible entre "panier" (le nom), "nier" (le verbe), "Rénier" (famille princière de Monaco) d'une part et d'autre part "reigner" qui utiliserait soit-disant un [ɲ]. A la limite on peut seulement admettre une différence quand c'est en position finale suivie d'un e muet. Mais "gnou" ou "biniou" sont identiques. Quant à "gnome" ce n'est pas prononcé comme le digraphe mais comme deux consonnes rapprochées [gn] mais audibles distinctement (avec le [n] souvent affibli mais le [g] est toujours bien là et non fusionné) et pas comme [ɲ]. "les rognons" et "nous renions" sont aussi identiques, de même "rognait" et "reniait"...
Bref des références il y en a des miliers et sans limitation, elles sont innombrables, on n'a que l'embarras du choix. verdy_p (talk) 01:32, 11 June 2008 (UTC)

TfD nomination of Template:Sin[edit]

Template:Sin has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for Deletion page. Thank you. —Remember the dot (talk) 05:10, 11 May 2008 (UTC)

Sourcing guide[edit]

What made you feel a references section was necessary at the end of a file that is transcluded into a guideline?[1] Most guidelines don't have references.—Kww(talk) 21:01, 12 September 2009 (UTC)

There was a MediaWiki error message appearing at end of the page. Effectively the refernces are dummy and need fixing or need to be dropped if they are fake. verdy_p (talk) 21:05, 12 September 2009 (UTC)
That's very strange: that error is supposed to be suppressed outside of article space. When I view WP:Record charts, there is no error showing. What message do you get, and where does it appear?—Kww(talk) 21:08, 12 September 2009 (UTC)
The red error message shows that there's a missing references tag, because there are ref tags in the article... (they contain "fake reference"). verdy_p (talk) 21:11, 12 September 2009 (UTC)
I know what they contain (I wrote them), but I'm still surprised. You are getting the large red message at the bottom of the page when you view WP:Record charts? What browser are you using?—Kww(talk) 21:15, 12 September 2009 (UTC)
Anyway, when I edited the article, I thought I was editing a section of the page, to add another one after it, and not in the subpage; the section was added to the subpage where there are no ref directly.
This still signals an error in the article itself. May be the references section should be in the main page, possibly made invisible (display:none) if these refs are really intended to be fake.
The error message does appear in my Chrome, as well as in IE8 and Mozilla. This is standard behavior of MediaWiki to display these strong red error notices, and it is not supposed to be hidden, depending on the browser used. verdy_p (talk) 21:17, 12 September 2009 (UTC)
Note: you undid this change, but this restores the error message at end of the page (on ALL browsers)... This was what I wanted to fix. The main page still needs fixing. Look at it to find a solution if you created it. verdy_p (talk) 21:20, 12 September 2009 (UTC)
The error message shows this exactly : Erreur de citation : Des balises <ref> existent, mais aucune balise <references/> n’a été trouvée..
Note that my preferences are to use the French localisation of MediaWiki: did you implement some custom filter specific to some localisation (only english here) and to a specific theme (I just use Monobook, there are problems with the new "accessibility" theme, that is blocking some existing features and most gadgets that I still need and that do not work without Monobook).
I don't know what you did to suppress such error messages, but it is against the usage policy and anyway it does not work for the simplest configurations. verdy_p (talk) 21:26, 12 September 2009 (UTC)
I did not do anything on purpose. That is why I am asking you to make the edit to include the reflist with display:none. I don't know how to use display:none, and, since I don't see the error message normally, I could not tell if I had fixed the problem. Please make the edit for me, so that it can be done properly.—Kww(talk) 21:29, 12 September 2009 (UTC)
I use Mozilla 3.0, and receive no error message on the page. I do see those red messages when people leave the reflist off in article space, and I thought it was namespace dependent. You are the first to mention this, and I made the change weeks ago. They are supposed to be suppressed: they are just to illustrate the position in a record chart that the references should be placed. I don't know how to use "display:none".
Could you add a reflist with display:none to the end of WP:Record charts?—Kww(talk) 21:23, 12 September 2009 (UTC)
Done, at the appropriate place (with a comment to explain why it is present). verdy_p (talk) 21:30, 12 September 2009 (UTC)
Thank you.—Kww(talk) 21:37, 12 September 2009 (UTC)
Note that this is NOT browser-dependant. MediaWiki ALWAYS generate it in the HTML (it is NOT namespace-dependant). There is only a site-specific customization to avoid the message when displaying the template page itself only, but not in every other pages (including talk pages, or other namespaces, not just the main namespace), and this customization (in JavaScript ?) is just valid with the default preferences. For all other cases (including alternate themes, notably those for usability), the message will still appear. verdy_p (talk) 21:39, 12 September 2009 (UTC)
I'm still very confused by where the suppression is happening. I use the default English Wikipedia skin, no custom styles, no Javascript files, nothing.—Kww(talk) 21:44, 12 September 2009 (UTC)
May be this is some custom javascript added on this site (default Monobook.js? May be it is just searching for the message in English and ignores the fact that this message is localized by default according to user's language preferences; these language-specific messages may change over time, including in English, so they may reappear at anytime; it's a bad idea to look for the text of specific messages, they should look for message classes instead).
Anyway, if I have effectively setup my users preferences to French, I don't have any user-specific javascript on this wiki, but just some cutomizations of CSS for handling fonts and many linguistic scripts (i.e. scripts other than Latin, or to use better fonts capable of displaying them all, with priorities according to languages). I use a shared CSS, imported into all the wikis, from my main user profile on French Wikipedia. This CSS is linked from various places in help pages where it is given as an example (and it has been imported as is in several other wikis by default, because it was proven to be useful). My custom scripts and CSS are linked from my user page. You'll see by yourself that they do not make anything about MediaWiki messages. verdy_p (talk) 21:48, 12 September 2009 (UTC)
Another final note: the HTML code that is styled with CSS "display:none" may still be visible in some browsers, if the CSS is disabled. This is not a bad thing by itself and can be useful sometimes (for debugging purpose); but MediaWiki should offer a way to eliminate this HTML code completely by using some class, recognized by the parser, and permitting compatibility with browsers that don't support CSS at all (for example a mobile version of WikiMedia sites). Currently this is not needed, because other proxying sites, made for mobile phone users or for users with accesibility constraints, are using their own renderer for the WikiMedia site contents, and will filter out those things that should not be rendered and where CSS support on simple mobile phones is not implemented, and where navigation uses very different layout. So the "display:none" CSS is the correct option for most users of traditionnal graphic browsers (including for rendering to the printed paper media, or for oral rendering, or for Braille rendering). The Foundation actively supports the development of such proxying sites (for all rendering purpose, as permitted by the acceptable licences) even if it restricts some interactions (articles editing and possibly talk pages editing too) when accessing to WikiMedia servers via proxies (there may be acceptable proxies that permit such interaction, if they provide actual tracing of users and implement acceptable usage policies, enforced by their local admins, and when they collaborate to extend the common WikiMedia site policies to their own proxies and all their users). verdy_p (talk) 22:59, 12 September 2009 (UTC)

Sandhi (Sandy)[edit]

Hi, just curious — re this, what's the difference? Was the change necessary? Shreevatsa (talk) 05:17, 4 October 2009 (UTC)

First names take a capital... The adjective also has several prononciations in English (including all those shown in the article for the term sandhi), derived from the multiple prononciations of the noun sand.
With the first name it is less ambiguous, especially for non-native speakers of English, that may not know or use the adjective, but that would more likely know the first name present in many artistic records (notably in songs), or heard more frequently in famous people names. verdy_p (talk) 10:06, 4 October 2009 (UTC)

Wikipedia:Book sources[edit]

I didn't mean to do any more than change "Carribeans" to "Carribean". It seems that we were editing at the same time and for some reason an edit conflict wasn't flagged when I saved my edit. Phil Bridger (talk) 19:05, 20 November 2009 (UTC)

OK, But I have later changed it again into Caribbean (this is the orthography most widely used, and found in the referenced article, despite it seems to forget that multiple orthographies exist, and that the term is commonly found also using the plural in many documents). Sorry for this confusion, this should be OK now. verdy_p (talk) 19:08, 20 November 2009 (UTC)

{{Template:su}}[edit]

Hi, Unfortunately, your recent changes to {{su}} relusted in garbage output in MSIE 7.0 on Windows XP (other OSes not tested), so I had to revert them. I appreciate your efforts, so please do try and re-apply your changes, but make sure to test that they render correctly in all browsers before making them final.     — SkyLined (talk) 11:00, 15 March 2010 (UTC)

It's impossible to test ALL browsers. Windows XP is deprecating (Microsoft no longer supports it, and no longer sells it), as well as MSIE 7 (IE 8 is more current). This is now a very small platform, compared to the still wider IE6 platform (mostly used on NT) and IE8. also there are lots of other browsers, they all adopted the standard, and the old very specific quirks of IE7 on a specific old version of Windows is not something that can be tested because I no longer have it, and most people around me will probably also not have it.
Note that almost all remaining XP users are already using IE8, or any other competitive browser if they did not want Vista (and are still not using Seven, which is finally a valuable upgrade from XP).
I have a virtual installation of XP, but it is running IE8 only.
So instead of reverting, you shoiuld better explain what happens really and what can be made to override it, and you should have wondered if this was really causing big damages. If someting complicates the adoption of standards supported everywhere (including by Microsoft in IE8 and later versions), why should we continue to support those quirks ?
Is the result really disastrous for IE8? Can't we instead think that the change will be better for the overwhelming larger majority of users of more recent browsers ?
You did not provide any screenshot of what you get. Please avoid reverting things without understanding the need for the change. And consider that you really have a poor browser on a poor and unsupported OS. Time to upgrade ? verdy_p (talk) 17:48, 20 March 2010 (UTC)
In addition, I would say that the bug you apparently detected on IE7 was in fact visible in IE8, but it was NOT caused by me, but by YOU when YOU further edited my code (in YOUR attempt to "factorize" and remove the special tests for empty exponent or indice: it IS needed to use the sub and sup templates instead).
It is wellknown that putting two exponents and indices one below the other is difficult due to browsers quirks. It is not difficult with browsers that have adopted the CSS standard correctly.
That's why we need to use the special CSS code in this template ONLY when BOTH the exponent and indice are present, and then revert to use the existing sub and sup templates if only one is present.
I have then NOT changed the IE quirk bug you reverted, it was already present, even before me (IE has never been, and is still not, supporting the "display:inline-block" CSS option which is used in this template; for IE we should use table cells in some versions, and in some others it is impossible to perform the wanted layout so it will be best to simply display the indive and exponents one after the other even if they don't stack).
What I did was to avoid minor display problems (correcting the line-height, and adoiding partially hidden character glyphs, by correctly setting the background, and nothing else.
My opinion is that we should avoid using custom CSS in this template when trying to reproduce this effect, but instead we should use CSS class names, and define them in their appropriate stylesheets, so that IE quirks will be gracefully handled in the IEquirks CSS stylesheets. verdy_p (talk) 18:06, 20 March 2010 (UTC)
It seems I somehow pissed you off, for which I am sorry. I did not intend to offend you, I was only trying to point out that your edits had some negative side effects and that I reverted them to prevent this. It appears that I was indeed wrong about this, for which I am sorry. However, considering that I developed the original template code and that my intensions were good, I do not think the tone of your reaction is justified. I did not vandalize or make random changes, I reverted an edit to a template that I created that I thought damaged Wikipedia, which IMHO is a good thing to do: the damage would have been worse if I had not been wrong and left the changes.
I have VMs with MSIE 6, 7, 8, Safari 3, 4, Opera 10, Firefox 3.0, 3.5 and 3.6, which I used to develop this template and still use to test any changes made to it. I think we should aim to create code that works in the top 99% of internet browser (ordered by number of users) and more if possible. Wikipedia actually has some statistics that contradict your assumption that IE7 is not widely used. You ask why we should continue to support quirks: we are not here to force people to update their browser, but to create an encyclopedia that can be accessed by as many people as possible and provides useful information, not perfectly rendered information.
I have checked the changes you made since I reverted your edits in all browser mentioned above and they look good, thanks for that! I have been trying to remove the special case code that is used when only one argument is provided because it renders at a different height in some browsers. Using the same code for every situation would make sure it renders the same every time. If you have any suggestions about how to do this, please let me know!
Cheers,     — SkyLined (talk) 16:39, 22 March 2010 (UTC)
Unfortunately, yes this problem is wellknown and not easy to solve for all browsers, because IE still behaves very badly (even IE8) and still doesnot support the "inline-block" display mode (the only way to have it working with IE6 would be to use the <ruby> element, but then it would no longer work correctly in other browsers (whose support for ruby-text is also minimalist, as it has not been intended for that, and the Ruby module in CSS is still experimental and works only for the simplest case, but does not allow a precise definition of font heights and relative positioning of the ruby text in a way that is portable across the few browsers that support this module). verdy_p (talk) 16:05, 25 March 2010 (UTC)

You are now a Reviewer[edit]

Wikipedia Reviewer.svg

Hello. Your account has been granted the "reviewer" userright, allowing you to review other users' edits on certain flagged pages. Pending changes, also known as flagged protection, is currently undergoing a two-month trial scheduled to end 15 August 2010.

Reviewers can review edits made by users who are not autoconfirmed to articles placed under pending changes. Pending changes is applied to only a small number of articles, similarly to how semi-protection is applied but in a more controlled way for the trial. The list of articles with pending changes awaiting review is located at Special:OldReviewedPages.

When reviewing, edits should be accepted if they are not obvious vandalism or BLP violations, and not clearly problematic in light of the reason given for protection (see Wikipedia:Reviewing process). More detailed documentation and guidelines can be found here.

If you do not want this userright, you may ask any administrator to remove it for you at any time. Courcelles (talk) 01:19, 18 June 2010 (UTC)

Speedy deletion nomination of Utilisateur:Verdy p/monobook.js[edit]

Ambox warning pn.svg

Thank you for experimenting with Wikipedia. Your test worked, and the page that you created has been or soon will be deleted. Please use the sandbox for any other tests you want to do. Take a look at the welcome page if you would like to learn more about contributing to our encyclopedia. You may also wish to consider using a Wizard to help you create articles - see the Article Wizard.

If you think that this notice was placed here in error, you may contest the deletion by adding {{hangon}} to the top of the page that has been nominated for deletion (just below the existing speedy deletion or "db" tag - if no such tag exists then the page is no longer a speedy delete candidate and adding a hangon tag is unnecessary), coupled with adding a note on the talk page explaining your position, but be aware that once tagged for speedy deletion, if the page meets the criterion, it may be deleted without delay. Please do not remove the speedy deletion tag yourself, but don't hesitate to add information to the page that would render it more in conformance with Wikipedia's policies and guidelines. Lastly, please note that if the page does get deleted, you can contact one of these admins to request that they userfy the page or have a copy emailed to you. Sheeana Talk 00:55, 3 July 2010 (UTC)

This was already solved. This was just a confusion in the namespace name when navigating from one Pedia to the other. It has already been renamed, and I had even proposed the deletion of the redirect created by the renaming... verdy_p (talk) 09:52, 6 August 2010 (UTC)

Template:List of Colors[edit]

I see you have done some edits on the template above. Would you help on nominating a consensus if the template should stay or not. Thank you. Jhenderson777 (talk) 22:44, 4 August 2010 (UTC)

No opinion. I did not create this template, just regrouped matching colors according to its existing classification (primary/secondary colors). verdy_p (talk) 09:53, 6 August 2010 (UTC)

August 2010[edit]

Information.svg Welcome to Wikipedia. Everyone is welcome to contribute to the encyclopedia, but

I am NOT new to this Wikipedia... verdy_p (talk) 04:21, 12 August 2010 (UTC)

when you add or change content, as you did to the articles Continued fraction and Generalized continued fraction, please cite a reliable source for the content of your edit. This helps maintain our policy of verifiability. Take a look at Wikipedia:Citing sources for information about how to cite sources and the welcome page to learn more about contributing to this encyclopedia. Thank you. Glenn L (talk) 04:11, 12 August 2010 (UTC)

This algorithm is an obvious evolution from the canonical algorithm. It changes almost nothing, and it is used in many numerical recipes, in preference to the canonical representation. In fact, even the article about the "canonical" continued fractions gives examples for the generalized continued fraction representations of pi.
My addition is provable and demonstrated by the text of the addition itself (because it was an example). It adds NO complexity (and in fact did not change at all the algorithm which is the same), and also shows that negative numbers have similar, but different forms. It's also a reformulation, because the article said incorrectly that the GCD algorithm was needed to compute this form, when it is absolutely not (intermediate fraction in the computation NEED NOT be simplified as an irreductible a+b/c form (with b<c) as they can stay directly in the fraction form a/b (this is faster to compute in most cases, notably manually, but also in a computerized algorithm, where the GCD is not obvious and requires many additional steps, that will be taken anyway in the rest of the transform to the continuous form).
Also I had NOT removed the simplification step, I just said that they are optional (and inherent to rational numbers, that are not presented in that article). So these simplications were absolutely not necessary in the shown table.
I really hate when people delete ALL content that they simply can't read and understand. This is destructive antiocollaborative behavior of yours !!!
verdy_p (talk) 04:20, 12 August 2010 (UTC)

Changes to Ascii85 article[edit]

Hi. Thank you for your contributions to the Ascii85 article, but I think that the new sections are excessively detailed and should be drastically shortened or even removed again. FYI, I have started a discussion on the talk page page about this. — DataWraith (talk) 16:57, 16 August 2010 (UTC)

Cantillation[edit]

Hi,

There is a note you added to Cantillation a long time ago:

  • The mark for U+05AA (yerach ben yomo or galgal) should not be drawn with the bottom vertical tick used in the mark drawn for U+05A2 (atnach hafukh), however some fonts draw these marks identically.

(see [2]). Do you have any reference for it? I was unable to find anything that supports this observation.

I would be truly grateful to you! Iorsh (talk) 07:08, 3 September 2010 (UTC)

When I wrote it, it was in 2008, and default fonts for Windows XP had this problem. I think it is still the case today (XP is still not dead, and the fonts have also been borrowed into other systems). Many open fonts also made this error, as the two cantillation marks are easily confusable (including when they are handwritten). This has also caused some texts to be encoded using one for the other. verdy_p (talk) 09:06, 4 September 2010 (UTC)
I didn't express myself clearly. Why do you think the bottom vertical tick should not be drawn? I saw a few quite old sources, and they use both forms. Could you please give a reference which states which "galgal" form is correct? Iorsh (talk) 07:46, 16 September 2010 (UTC)
Start with the Unicode standard, look at the Unicode charts more closely. The two characters are distincguished, but what I wrote is still true: even if there exists some texts at confuse both glyphs, when atnash hafukh is intended, it MUST use the vertical tick mark only. And there exists cases where they MUST be distinguished.
IT's a case quite similar to the distinction between the two gorms of Latin letters a or g (with a single or two bowls) : frequently tou don't see the difference, but there exists frequent cases where they must be distinct and these letters are using a prefered form and an alternate form, One of these forms is also encoded separately when the other form MUSt not be used. Similar cases exist with the cedilla and the comma-below in Romanian (the comma below is prefered, so there are fonts that represents cedillas in such a way that, on first look, it may also be easily confused with a comma below, notably in small resolutions). In all these cases, there's a preferred form, and a legacy non-preferred form that should be avoided.
I have not spoken about which character to encode, just about the glyphs that fonts should adopt to draw them, and that should be distinct : the vertical tick form for galgal is highly discouraged (because it looses a distinction which will be frequently necessary in many texts containing one or the other cantillation mark). verdy_p (talk) 00:45, 17 September 2010 (UTC)

URL[edit]

Thanks for the improvements. I had meant to add the "titleparts" stuff to extract the domain name, but never got around to it. Thanks again. Plastikspork ―Œ(talk) 22:39, 10 October 2010 (UTC)

By the way, I saw your comments at VPT. I completely agree that the URL template is overkill. I was thinking it might be good idea to have a bot go around and replace transclusions with standard external link syntax. Plastikspork ―Œ(talk) 22:54, 10 October 2010 (UTC)

One more thing, after the cache has cleared, should I delete {{Val/delimitnum/logic}}. Also, if there are any other unused subtemplates, let me know and I can delete them as well. Thanks! Plastikspork ―Œ(talk) 22:54, 10 October 2010 (UTC)

I'm sandboxing those templates to see how I can improve how they work, or find other workarounds.
Effectively {{Val/delimitnum/logic}} is no longer used (the remaining references are within blocked pages, even though they habe been purged and no longer use it, only because ther list of references stored in the database cannot be purged unless these blocked pages are saved with a null edit' by an admin...
Note also that I stripped the display of the trailing default "/" path in canonical URLs like "http://www.example.com/" ; but there's no solution for now with long URLs because of a limitation of string lengths that can be processed by {{#titleparts:...}}; see Template:URL/testcases.
Anyway, my new code solves a SEVERE performance problem when using {{Str left}} or {{Str right}} : now it is used ONLY on the shorter domain name extracted by {{#titleparts:...}} (at least for the most frequent URLs that are not too long to avoid the {{#titleparts:...}} limits).
And I agree with you: really, infoboxes should absolutely avoid using {{URL}}, and it will be much preferable to provide the display text separately instead of generating it automatically with such costly template.
For now, the infoboxes (and stub templates) used in so many pages are creating lots of server performance degradation when they use those very costly (and bogous in fact) String manipulation templates. My edit allowed reducing this huge cost on most cases (short URLs).
verdy_p (talk) 23:07, 10 October 2010 (UTC)
Okay, I can take care of the "null edits" if you need me to do so. Let me know if you need me to delete anything. I also operate a bot, so I can make massive edits if they are uncontroversial. Thanks again. Plastikspork ―Œ(talk) 23:18, 10 October 2010 (UTC)
Note: the URL template will not work as expected (independantly of length limitations), if the specified external URL contains any kind of URL encoding for characters in its query string or path (not accepted by the titleparts parser function !) ; for example, with http://www.example.com/?%2E we get the wrong display: www.example.com?..
I just documented it as well in the pathological test cases, it should be documented in the main documentation, because this case is in fact frequent... (And I really wonder why titleparts does not simply uses a basic split on slashes, and needs to parse the specified string before). I may find a workaround for these cases (by testing that titleparts effectively changes the string returned).
verdy_p (talk) 23:24, 10 October 2010 (UTC)

Civility[edit]

Bogus (note spelling) is a very confrontational word that you should consider using less frequently. OrangeDog (τ • ε) 10:31, 13 October 2010 (UTC)

I don't use it personnally, it is fully impersonnal and qualifies the behavior of incorrect code (related to "bug", « bogue » in French). It was not my intent to be confrontational, and even my words were clearly indicating the impersonnal usage (it was only used to qualify code and never any person).
OK, is it really "buggy" ? "bugful" ? note that English is not my primary language, sorry if this goes far away from my intent. verdy_p (talk) 14:09, 13 October 2010 (UTC)
Ah, I figured it was a language issue. "Broken" is probably best, but "buggy" or "full of bugs" can be used if the code has lots of different problems. OrangeDog (τ • ε) 18:04, 13 October 2010 (UTC)

Re: Village pump (technical) discussion[edit]

Nuvola apps edu languages.svg
Hello, Verdy p. You have new messages at Wikipedia:Village pump (technical).
You can remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.

Zntrip 19:08, 19 October 2010 (UTC)

I don't know where the message is. Which discussion ? Where am I cited or concerned ? verdy_p (talk) 12:39, 21 November 2010 (UTC)

Val template[edit]

You recently made a change to the {{val}} template to balance the position of the times symbol. You should know that days and days of effort went into achieve a best compromise on that. Different browsers and operating systems produce different appearances. We had a handful of editors sharing screen shots via e-mail of how things looked on systems as unique as iPhones.

The only thing I changed was to equalize the spacing width on each side of the times operator. There's no reason this should be different on iPhones or in any browser, supposing that these spaces should be adjusted differently on the left and on the right of this operator. In all cases these should be equal. Don't forget that even on iPhones, or Android smartphones, there's a zooming (pinch with two fingers), and these unblanced spaces become clearly visible. verdy_p (talk) 12:49, 21 November 2010 (UTC)

I also note that someone—maybe before your latest edit—messed up the grouping. There is never supposed to be a hanging single digit like this: 6.6260693×10−34 J·s. The progression is supposed to be two, three, or four digits in the last group. That aspect is per ISO convention and was agreed upon by a wide consensus when the val template was voted upon on WT:MOSNUM. Would you please fix those two things? Greg L (talk) 19:16, 15 November 2010 (UTC)

I have not changed anything in the grouping of digits, so this was already the case before this edit. Anyway I doubt your reference: ISO does not say anywhere that the last group should be at least 2 digits, in fact the ISO format does NOT use any grouping after the decimal separator, but only before it within the integer part... But if you read more, you'll see that for numbers with very high precision (like enumerating thousands decimals of pi), the digits are generally grouped by five, because it allows easier counting of decimals for numbers that will span several or many lines of text.
Some online databases showing numbers with very high precision use diverse conventions. The most common one however is simpler: just group them by 3, like in the integer part as well, even if this leaves a single digit isolated.
Don't confuse this with the formatting of dates (e.g. "2010" : no grouping at all for years, i.e. not "2 010"). Here again this template is not used for formatting dates, so this does not apply.
So I don't know where to fix it. The logic that computes the number of digits to display was already there before and is only the result of a complex logarithmic expression that did not change. If there was a change it is not in what I edited, because fractional parts of the number was already formatted using "{ {formatnum:...} }". An I absolutely don't see any trace of the "consensus" you're speaking about here, and others that have edited the template before me have certainly not seen such as trace if they ever changed the implementation before me.
If you really did not want to have a single digit in the last group you should have included such a case in the documentation, nothing traces back the behavior you're describing or wanting, and in fact, after looking at the discussions, there's nothing about what you are saying here ("WT:MOSMUM" just speaks about the choice of SI units and the presentation of these units, or about presentation of dates of birth/death after people name for bibliographies). verdy_p (talk) 12:49, 21 November 2010 (UTC)
This needs to be discussed in one venue where others can see it. Please see Template talk:Val is now screwed up. In a nutshell, the BIPM and the NIST and every other standards organization uses a last group of four digits so as to never leave a single hanging digit. By wide consensus, Wikipedia follows that practice and does not want a house style that flouts international conventions.Links are provided on the page. As for “documenting” this stuff, I’m not a template author. I helped coordinate all this stuff and didn’t anticipate what the passage of time would allow. Greg L (talk) 18:33, 25 November 2010 (UTC)

Val formatting error remarks[edit]

Hey, I noticed you changed the wording to NOT make a change to the page. Have you tested this? I wrote the original and was under the impression that a small change was needed, or the server would simply ignore the update.     — SkyLined (talk) 14:28, 30 November 2010 (UTC)

What ? Where ? Can you precise what you mean here, or what you are asking me ? Do I need to perform further corrections ? verdy_p (talk) 04:57, 2 December 2010 (UTC)
If you are refering to null edits, this is true. Just saving the page solves exactly the same issues as saving it by adding some invisible spaces. This does not solve the temporary bug that reoccurs after several minutes for phantom categories. So adding spaces is just a pollution in the page edit history which does not help saving the bug of phantom categories. There's currently NO solution for this problem, which is really a bug in Mediawiki (which apparently restores some old data from its cache when rendering pages and updating categories in the dependency list (most probably a parsing error that ignores #if conditions for conditional categories, when the background updater attempts to revalidate later the edited page and forgets to clear some internal cache).
Any edit (including non-null with true edits) will cause this bug of reappearing categories to happen once again. There's currently no solution, and there's really no need to add any spacing when performing null edits. It's still best to do nothing else and save the page as is without introducing any phantom spaces or newlines). A bug is filed in BugZilla about these old categories, it needs further investigation.
Believe me, adding spaces does not help at all ! I have tried it and it does not make any difference with a null edit when saving the page as is. So let's avoid polluting histories with such null edits verdy_p (talk) 05:05, 2 December 2010 (UTC)

Sorry about being a bit vague: yes, I was referring to null edits and the phantom category problem. Thank you for investigating and explaining - not further action needed. :)     — SkyLined (talk) 09:31, 2 December 2010 (UTC)

I think that this is caused by a synchronization issue between multiple cache servers for the database. It looks like a few of them are out of sync and are being used to parse old versions of the included templates or pages, or that they are not refreshed when they are instructed to do so (possibly a configuration issue in a few of them) ; it's even possible that some cache is not synchronizing its date/clock correctly or that they are running in the wrong year. This could also be caused by NFS caches.
We cannot solve it by editing pages, only Wikimedia admins can investigate the state of webservers, file servers, database servers, and proxies, with a Bugzilla report. verdy_p (talk) 15:59, 3 December 2010 (UTC)

Notification: changes to "Mark my edits as minor by default" preference[edit]

Hello there. This is an automated message to tell you about the gradual phasing out of the preference entitled "Mark all edits minor by default", which you currently have (or very recently had) enabled.

On 13 March 2011, this preference was hidden from the user preferences screen as part of efforts to prevent its accidental misuse (consensus discussion, guidelines for use at WP:MINOR). This had the effect of locking users in to their existing preference, which, in your case, was true. To complete the process, your preference will automatically be changed to false in the next few days. This does not require any intervention on your part and all users will still be able to manually mark their edits as being minor in the usual way.

For well-established users such as yourself there is a workaround available involving custom JavaScript. If you have any problems, feel free to drop me a note.

Thank you for your understanding and happy editing :) Editing on behalf of User:Jarry1250, LivingBot (talk) 21:08, 15 March 2011 (UTC)

Arabic diacritics article[edit]

Hi Verdy. Make sure you edit your customized CSS for the Vector skin. Help:CSS. All the ‹<big>...</big>› added to Arabic diacritics article have to be reverted.

For ideas about your customized CSS to change the style of how the Arabic text would look like, you may add that phrase:

span[lang|=ar] { font-size: 130%;
   font-family: "FONT ONE", "FONT TWO", FONT3; }

In place of "FONT ONE", "FONT TWO", FONT3 add your preferred fonts and in place of 130% you may increase the number to have bigger font-size. Thanks. --Mahmudmasri (talk) 16:30, 21 September 2011 (UTC)

Stupid reverts. The code I replaced was completely invalid, I used standard code, and I did not need to add the arabic markup which was already there. verdy_p (talk) 07:47, 22 September 2011 (UTC)
And you have also removed necessary punctuations. Your suggestion above is also completely irrelevant, I have removed ALL font markup, not added it it the article. I have corrected all incorrect font sizes, incorrect HTML syntax, and so on... And many inconsistencies as well throughout the article, notably in style, to make it really readable, but still preserve the intent. Please do not remove ‹ › which is delimiting punctuation, not markup (and it was already used before my edits in the article, I did not want to remove them, just make them consistantly used) ! verdy_p (talk) 07:54, 22 September 2011 (UTC)

GSM encoding[edit]

Your edit http://en.wikipedia.org/w/index.php?title=GSM_03.38&diff=445295898&oldid=445292294 seems to be wrong. At least I cannot find any mention of those National Shift Tables in the relevant standard. — Preceding unsigned comment added by Sealibora (talkcontribs) 09:03, 11 October 2011 (UTC)

There are explicit mentions about their existence ! But I have not said that all languages had their national shift table, just some of them, and not completely to offer full coverage of the needed characters... Still many phones do not even display the standard 7-bit extension codepage which is full of unallocated positions (so many phones do not even display the euro symbol, and display an "E" instead, ignoring the previous ESC or rendering it as a space) verdy_p (talk) 15:11, 11 October 2011 (UTC)

I was talking about this paragraph:

But a revision of GSM 03.38 (in specification document CR 007, version 4.2.0 of september 2001) has added support for more languages using a 7-bit national shift table : English (extended), German, Dutch, Swedish, Danish, Finnish, Norwegian, French, Italian, Hungarian, Polish, Czech, Icelandic, Greek, Russian, Hebrew and Arabic, in addition to the previous languages. Unfortunately, many smartphones (and national operators) still don't support these extensions.

There is no shift table for russian, only place where russian is mentioned in 03.38 is in CBS encoding and that a bit different thing than shift table. Sealibora (talk) 14:39, 12 October 2011 (UTC)

You have not downloaded the specified revision I have indicated. You are talking about the first edition of GSM 03.38, this paragraph speaks about the September 2001 revision...
Really there are such tables for the list of languages indicated (but the document itself does not list the exact content of these tables, which should then be seeked in national standards for which this update was made). verdy_p (talk) 15:28, 12 October 2011 (UTC)

Disambiguation link notification[edit]

Hi. When you recently edited ISO 3166-1 alpha-2, you added a link pointing to the disambiguation page IANA (check to confirm. (talk) 10:32, 28 February 2012 (UTC)

Fixed, thanks. verdy_p (talk) 12:58, 28 February 2012 (UTC)

Disambiguation link notification for March 6[edit]

Hi. When you recently edited GSM 03.38, you added a link pointing to the disambiguation page Colon (check to confirm | fix with Dab solver). Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ • Join us at the DPL WikiProject.

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 10:40, 6 March 2012 (UTC)

Fixed. I also wonder why the target page of the Urdu kāf letter is a disambiguation page instead of an article explaining this character in more details. verdy_p (talk) 20:59, 6 March 2012 (UTC)

Disambiguation link notification for March 13[edit]

Hi. When you recently edited Uyghur alphabets, you added a link pointing to the disambiguation page Hiatus (check to confirm | fix with Dab solver). Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ • Join us at the DPL WikiProject.

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 11:01, 13 March 2012 (UTC)

Solved. verdy_p (talk) 01:45, 14 March 2012 (UTC)

Category:Persian-Urdu Arabic numerals[edit]

Category:Persian-Urdu Arabic numerals, which you created, has been nominated for discussion. If you would like to participate in the discussion, you are invited to add your comments at the category's entry on the Categories for discussion page. Thank you. LeSnail (talk) 22:31, 13 March 2012 (UTC)

Category:Bengali numerals[edit]

Category:Bengali numerals, which you created, has been nominated for discussion. If you would like to participate in the discussion, you are invited to add your comments at the category's entry on the Categories for discussion page. Thank you. LeSnail (talk) 22:32, 13 March 2012 (UTC)

Category:Devanagari numerals[edit]

Category:Devanagari numerals, which you created, has been nominated for discussion. If you would like to participate in the discussion, you are invited to add your comments at the category's entry on the Categories for discussion page. Thank you. LeSnail (talk) 22:35, 13 March 2012 (UTC)

Category:Gurmukhī numerals[edit]

Category:Gurmukhī numerals, which you created, has been nominated for discussion. If you would like to participate in the discussion, you are invited to add your comments at the category's entry on the Categories for discussion page. Thank you. LeSnail (talk) 22:35, 13 March 2012 (UTC)

Disambiguation link notification for March 20[edit]

Hi. When you recently edited South Asian numbering system, you added a link pointing to the disambiguation page Billiard (check to confirm | fix with Dab solver). Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ • Join us at the DPL WikiProject.

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 10:12, 20 March 2012 (UTC)

Category:Eastern Arabic numerals[edit]

Category:Eastern Arabic numerals, which you created, has been nominated for discussion. If you would like to participate in the discussion, you are invited to add your comments at the category's entry on the Categories for discussion page. Thank you. LeSnail (talk) 05:11, 21 March 2012 (UTC)

Category:Arabic numerals[edit]

Category:Arabic numerals, which you created, has been nominated for discussion. If you would like to participate in the discussion, you are invited to add your comments at the category's entry on the Categories for discussion page. Thank you. LeSnail (talk) 05:11, 21 March 2012 (UTC)

Arabic alphabet shapes[edit]

Please, see the Template talk:Arabic alphabet shapes. --Mahmudmasri (talk) 04:18, 6 May 2012 (UTC)

Sans-serif IPA fonts[edit]

Hi, do you know a sans-serif font which displays all IPA characters and diacritics, other than DejaVu Sans, Segoe UI, Lucida Sans Unicode, Microsoft Sans Serif, Arial, Arial Unicode MS.

I really can't get satisfied with my sans-serif fonts and I don't want to use serif fonts for that. I searched a lot.

  1. ⟨Il⟩: I want something to show a difference between the capital I and the small l (as in Tahoma, Segoe UI)
  2. ⟨g⟩: while showing the small g with an open tail
  3. ⟨t͡ʃ⟩: while not showing the tie-bar of the affricate/double articulation so high that it sometimes doesn't appear at all (as in Segoe UI).
  4. ⟨‘ ' ’ “ " ”⟩: It would be a plus if it differentiated between the shapes of the apostrophes and quotation marks ‘ ' ’ “ " ” because the most complete sans-serif IPA fonts don't distinguish them.

--Mahmudmasri (talk) 05:15, 7 May 2012 (UTC)

You can try with "Candara" (shipped with Windows 7)... verdy_p (talk) 06:18, 7 May 2012 (UTC)
You should also know that IPA is best designed with a serif font (all IPA references use IPA in a serif style since long). verdy_p (talk) 06:33, 7 May 2012 (UTC)
Thanks for replying. Well, Candara has the same problems I mentioned :( What are the fonts you use? (The fonts you use as the default font, the IPA font and the unicode font) --Mahmudmasri (talk) 02:17, 8 May 2012 (UTC)

Testing some more recently published or updated fonts (tested here with a font size increased to 125%)...

  • Sans-serif fonts (not very suited for IPA):
    1. Tahoma: abcdefgxyz, ABCDEFGXYZ, 0123456789, iIl1, oO0, g, t͡ʃ, ‹ ‘ ' ’ › « “ " ” ».
    2. Segoe UI: abcdefgxyz, ABCDEFGXYZ, 0123456789, iIl1, oO0, g, t͡ʃ, ‹ ‘ ' ’ › « “ " ” ».
    3. Calibri: abcdefgxyz, ABCDEFGXYZ, 0123456789, iIl1, oO0, g, t͡ʃ, ‹ ‘ ' ’ › « “ " ” ». (but g has closed tail)
    4. Candara: abcdefgxyz, ABCDEFGXYZ, 0123456789, iIl1, oO0, g, t͡ʃ, ‹ ‘ ' ’ › « “ " ” ». (but g has closed tail)
  • Serif fonts (better for IPA):
    1. 'Times New Roman': abcdefgxyz, ABCDEFGXYZ, 0123456789, iIl1, oO0, g, t͡ʃ, ‹ ‘ ' ’ › « “ " ” ». (but g has closed tail)
    2. Constantia: abcdefgxyz, ABCDEFGXYZ, 0123456789, iIl1, oO0, g, t͡ʃ, ‹ ‘ ' ’ › « “ " ” ». (but g has closed tail)
    3. Cambria: abcdefgxyz, ABCDEFGXYZ, 0123456789, iIl1, oO0, g, t͡ʃ, ‹ ‘ ' ’ › « “ " ” ». (but g has closed tail)
    4. Gabriola: abcdefgxyz, ABCDEFGXYZ, 0123456789, iIl1, oO0, g, t͡ʃ, ‹ ‘ ' ’ › « “ " ” ». (but g has closed tail)
    5. Quivira: abcdefgxyz, ABCDEFGXYZ, 0123456789, iIl1, oO0, g, t͡ʃ, ‹ ‘ ' ’ › « “ " ” ». (but g has closed tail, very complete, but beta version, not hinted)
  • Monospaced fonts:
    1. Consolas: abcdefgxyz, ABCDEFGXYZ, 0123456789, iIl1, oO0, g, t͡ʃ, ‹ ‘ ' ’ › « “ " ” ». (but g has closed tail)

Note that the punctuation pair ⟨...⟩ (single tall angle brackets on the baseline, normally used only in maths notations) that you use is extremely rarely supported (and not in any of these fonts), this causes the renderer to immediately seek for a fallback font in which it will locate the other characters after them, ignoring the suggested font... I really suggest avoiding these punctuations (which immediately brings a mathematical font or a default fallback font, not suitable for IPA or for extended Latin and Greek), and to use instead better typographic brackets like ‹ › (single guillemets, whose height is similar to the double guillemets « », i.e. the height similar to lowercase letters). For surrounding East-Asian scripts (Hiragana, Katakana, Hangul, simplified Han sinograms, traditional Kanji/Hanja/Hanzi sinograms, Yi, and Bopomofo), I suggest using ideographic brackets 「」or their half-width variants 「」.

It looks like Tahoma is the best choice given your desires, for its coverage and distinctions, but still not very good for IPA which prefers a serif style. The tail of the g is never distinguished in all fonts above (so the IPA version and the standard Latin version are mapped to the same glyph).

Note also: the line-height should NEVER be specifed using a unit (such as '1.5em'); otherwise it will not grow in parallel with the font size; the line-height should be either "normal" to use the font's default, or should be unitless (such as "line-height:1.5"). This is the normal setting now in Wikimedia (I helped fixing this issue in Wikimedia stylesheets, to replace the previous "line-height:1.5em;" by "line-height:1.5;" and this immediately fixed all truncations occuring at the top of letters ins some contexts such as with big or superscript/subscripts, provided that this size is set at 1.5 or higher or set to normal)

As a final note, I wonder why there's still not a free font specially designed for IPA with its normative style with serifs (but discrete serifs), including the full coverage needed in the Latin subset and all the necessary IPA diacritics and IPA tone symbols (not not necessarily the full coverage of Latin), that Wikimedia could redistribute automatically using one of the now well supported featured webfont technologies (supported now in all Windows browsers as well as in recent versions of Android in Smartphones, HDTV devices with Embedded Opera, and iPhones).

Does that make unspecifying the line-height unit is treated by browsers as specifying it with em, most of the times, in HTML? --Mahmudmasri (talk) 14:35, 8 July 2012 (UTC)
The difference is that line-height with a unit is not inherited, while the unitless line-height is inherited when there are subsequent changes of font-sizes or superscripts or subscripts. With a unit, the line-height is computed on the element that sets it, but then it remains fixed for the whole content of the container element specifying it, according to the font-size of that container and not the font-size of the inner sub-elements (such as "small", "big", "sup" and "sub", or in case of a font-change, including implicit font-changes caused by usng font fallback or in multilingual texts). See the CSS reference documentation.
I have NEVER seen any advantage of using the line-height with a unit; they finally created problems of truncation or incomplete filling of the line-height which was not autoadaptable.
The line-height with a unit is only usable if you fully control the final layout : you know on which platform the redering will occur, and exactly with which font. For interoperability for which you have variable and unpredictable fonts to render the text (such as Wikis controbuted by various users using various tools on various platforms with their own font preferences), you need a more adaptative system, and should always remove the unit.
verdy_p (talk) 15:43, 8 July 2012 (UTC)

Research project relating to the Wikimedia Strategy Process[edit]

Dear Verdy p,

My name is Gordon Mueller-Seitz and my colleague, Leonhard Dobusch, and I are currently engaged in a research project relating to the Wikimedia Strategy Process that took place in 2009-2010. Our key interest is to explore how this strategy process actually unfolded.

In this connection, we started with interviewing WM personnel and promoters such as Eugene Kim in a first step. By now we want to broaden our insights in a second step and we would like to kindly inquire if it was possible to make a short telephone interview with you concerning the WM strategy process? If yes, we would very appreciate it if you could suggest a date/time that would suit you and the telephone number we could reach you on.

Thank you very much for a brief reply. We look forward to hearing from you.


Best wishes,
Gordon and Leonhard

--
Dr. Gordon Mueller-Seitz
Freie Universitaet Berlin, Chair for Inter-firm Cooperation
School of Business & Economics, Dept of Management
Boltzmannstrasse 20, 14195 Berlin (Germany)
Tel.: ++49 30 838 56359, Fax: ++49 30 838 56808
Gordon.Mueller-Seitz[at]fu-berlin.de
82.113.98.169 (talk) 11:52, 29 June 2012 (UTC)

I've not followed the project since long now. Except for helping a bit at the beginning to initiate the translation and structure its pages and discussions. After som months, the project started to produce some results but I no longer had time to follow it.
In my opinion, the Strategy wiki had the defect of being on a separate wiki with little visibility, where it should have better been in a new dedicated namespace on Commons (which already has the internationalization structure and is widely visited). The final results and reports for decisions could have been stabilized by exporting some stable versions on the WMF website (which is edit-restricted), or exporting corrected PDF copies to Commons on edit-protected pages.
Too many wikis kills the wiki as there's no easy way to follow them. verdy_p (talk) 13:53, 29 June 2012 (UTC)
Even though you were just involved in the beginning, it would still be very helpful for us to make a short telephone interview with you. Please let us know if you’re interested and if so, please send us your contact details via e-mail (Gordon.Mueller-Seitz[at]fu-berlin.de).
We look forward to hearing from you. Thank you. Gordon 87.77.7.111 (talk) 09:45, 6 July 2012 (UTC)
I replied to you via private email with contact info. verdy_p (talk) 15:44, 8 July 2012 (UTC)

Julian calendar edits[edit]

You have made a number of edits to the description of Sacrobosco's theory of month lengths on the Julian calendar page. Since the page is IP-protected, I am writing to you to ask you to revert them, because they are not relevant to Sacrobosco's theory (the subject of that section) and they are factually wrong, as well as being inconsistent with statements made elsewhere in the article.

1)The Lamont article cited in the article does not suggest that Sacrobosco discussed intercalation in the Republican calendar, and your description of it is wrong. Intercalation was achieved by adding a 27 day month after the 24th or 25th of February, for a net gain of 22 or 23 days, not 11 or 12. This is described earlier in the article. [However, if Sacrobosco really did say intercalation happened this way, then please keep the text, but make it clear that this is his idea, not yours, and please provide a citation.]

2) Sacrobosco assumed the year started in January before 45 BC, not March, and actually he was right about that. The original year started in March, but it had changed to January by 153 BC, as the article explains under "Year numbering".

3) Your statements about whether Augustus' changes were an innovation and what he achieved are not relevant to anything Sacrobosco said. Augustus was honoured for many things in 8BC, but not for his calendar changes.

Also, I see you have changed the table in the "Leap year error" section. I think the idea is an improvement, though some people may object that it is not NPOV. But, according to you, Ideler's theory "may be correct", yet according to the text after the table, Ideler's theory has been disproven by Brind'Amour, so for consistency that line should be moved to the second section, of theories which have been "proven to be incorrect".

--68.87.42.115 (talk) 21:44, 13 December 2012 (UTC)

Oh my. That was really NOT helpful. Hopefully someone who is willing to spend the time will clean it up.

BTW, Christmann really did say that leap years resumed in AD 7 (Caesarian year 52), not AD 8. A silly mistake, I agree, but it's what he actually said. See the page of his book cited and linked to in footnote 38. --68.87.42.115 (talk) 23:29, 14 December 2012 (UTC)

You're wrong, Christmann did not write that ! The quoted page just gives the dominical letters for 52 years in the Julius Caesar era, revealing their matching weedkdays, as well as if those years are leap or not.
He stated that Julian years 1 and 2 were not leap, but Julian year 3 was leap. If Christmann thinks that the Caesar's decree was in 46 BC (and not 45 BC), making Julius Year 1 = 46 BC, then the 1st (triennial) leap year occured (only after Caesar's death) in BC 44, and the triennial dates given in the table are wrong (they should all be incremented) and this is true as well for the date of restoration of the 1st Quadriennial leap years in Julius Year 52, which is 51 years after 46 BC (= -45 Astronomic year), and it falls in 51-45 = 6 AD.... Which is in fact worse.
But the date of restoration of quadriennial leap years does not mean that it will fall on a leap year, just that the calendar is now in sync and no longer justifies continuing the temporary ban of leap years, just that the 1st leap year cannot occur before. And the 1st Quadriennial leap year from 6 AD is still 8 AD...
What he writes is that the Julian and Gragorian calendars are in sync at least from 6 AD.verdy_p (talk) 00:22, 15 December 2012 (UTC)
Please read the previous page, where Christmann equates year 719 Nabonassar with year 16 Julian, and also explains that he is using the Julian era of Censorinus, so it's completely clear that he intended Julian year 1 = 45 BC, hence Julian year 52 = AD 7, not AD 6. His model realigns to the proleptic Julian calendar in AD 4, just as the table says, but it is out of phase with it for one year in four after that.
This is your interpretation. I'm quite sure that Christmann was not stupid about thinking that AD 7 was a leap year unless you state that his next leap year still occured in AD 12 instead of AD 11 (in which case the normal quadriennial leap years were actually not resumed in AD 7 but AD 12.)
You are certainly missing something about how to equate the Roman Julius era years to Julian BC/AD years. For now Christmann, just tried to correlate several Roman emperors eras, but not up to the 3rd century for the Concile of Nicea (which fixed an arbitrary epoch for the Christian BC/AD era with the Julian calendar). And in fact I'm not convinced (I have no real proof) that Christmann was wrong, but I'm convinced that his work is incorrectly interpreted in the BC/AD era. For me his first quadriennial leap year, after Augustus the pause, must be a leap year as well in the AD era of the Julian calendar, and it can only by in AD 4, or 8, but certainly not in AD 7 ; it is certainly not "out of phase for one year after that" (just consider when Christmann wrote his book, it was just at the time of the Gregorian calendar reform and it was extremely important at that time to perfectly align the Julian calendar before trying to correct it in a new calendar).
What I mean is that even if Christmann thinks that his triennial years are correctly aligned within the Juian calendar, and that the normal quadriennial years were applicable starting in AD 5 or AD 6 or AD 7, this could not happen before AD 8. Hence the dominical letter assigned to AD 7 cannot be leap but must be a single letter, not two, even if he thinks that Caesar's year 52 = AD 7 (not leap), which also means Caesar's year 53 = AD 8 (leap).
So there's no apparent contradiction to dismiss the Christmann opinion.
Note that there are soe difficulties as well to align Caesar's era years with Augustus' era years, just like with the various eras that have followed the Roman republican era up to the Concile of Nicea which fixed a single era since J.C (but without clearly stating what it was before or how the various Roman eras were correlated to the new Christian era). verdy_p (talk) 18:21, 17 December 2012 (UTC)
Brind'Amour's proof does disprove Radke but it also disproves Ideler, and for exactly the same reason. Radke's theory is also disproved by the Asian calendar reform, though Ideler's survives that test.
As to your other edits, what you have added in the Sacrobosco section is really just explaining the actual republican calendar, still not quite correctly (the year really did began in January, not March, in Caesar's time). It is repeating what is said elsewhere in explaining the motivation for the reform, and it isn't relevant to Sacrobosco's theories of the Julian calendar, which is what this section is about. Please remove it.
The very long section you have added explaining the Kalends, Nones and Ides also isn't relevant, because the Julian reform didn't change them. It is explained already, fairly clearly and much more briefly, in the Roman calendar#Months article, which is where it really belongs. This article could link to that discussion. It should probably say, in the Changes to the months section, that the Julian reform did not change the positions of the Kalends, Nones and Ides in any of the months. It's implied there but not said explicitly. But that's the most this article needs.
--71.136.32.166 (talk) 16:07, 17 December 2012 (UTC)
I won't reply if you don't say who you are, for me it's just an unsigned attack. Waht I indicated in the reference table giben is that NOTHING says clearly what was the opinion of the 3 authors cited in that table. The dominical letters are clearly insufficient (I don't know who wrote this handwritten table this is not said, but it is certainyl not the 3 authors cired in each column ; and it is not the same author as the one that added an interpretation of the Caesar's era years numbers to convert them into Julian year numbers (which only aligns with one author but not all of them).
In other words, there's no clear reference for now to say that Christmann was wrong when he assigned leap years to Caesar's years, or even dominical letters by equating 7-day weeks on them, simply because the Caesar's era years are not equated to Julian BC/AD years.
For now we lack references and I'm not even sure that someone really knows how to equate any Julian year before 4 AD with the previous Roman years in Caesar's era (there are in fact lots of troubles to correlate the various eras in the old Roman republic and empires, since the begining of the Romulus calendar up to the Concile of Nicea, dates are only known within one or two days up to about year 250 AD, and are certain only after the concile of Nicea unifiying the Christian empire to determine the date for Easter from the date of the vernal equinoxe ; but at that time many details had been forgotten or mixed because equinoxes were not properly aligned and were not determined on the same criteria : longitude and effect of height at a time when it was thought that the Earth was flat and the Sun revoluting around it like the Moon...). verdy_p (talk) 18:05, 17 December 2012 (UTC)

Julian day[edit]

I saw your old comments at Template talk:JULIANDAY, and I'm hoping you might help with a small project. In case you are not aware, a new system is available for writing templates: Lua scripts can be used, with a MediaWiki extension known as Scribunto as the interface between Lua and wikitext. Lua is much faster and cleaner than traditional template code.

I'm trying to help someone write a replacement for {{JULIANDAY}} and related calendar functions. However, we don't have the background to understand some issues. The problem boils down to this: Translating the JD formula into script gives correct results, but fails for a certain date.

The template docs say (and this is what the template does):

{{JULIANDAY|-4800|3|1}} returns -32410 (proleptic) (in year 4801 BC)

However, simple script gives a different result. For example, in Python:

def jdn(year, month, day):
    # Return Julian day number from a Gregorian calendar date.
    a = (14 - month)//12
    y = year + 4800 - a
    m = month + 12*a - 3
    return day + (153*m + 2)//5 + 365*y + y//4 - y//100 + y//400 - 32045

print jdn(-4800, 3, 1)  # outputs -32044

The discussion started at WP:Lua requests#Dates and continued at my talk, which contains this link to the testcases showing which dates agree with the template.

Would you mind explaining why the scripted attempts to implement the JD formula fail for (-4800, 3, 1). Johnuniq (talk) 00:39, 19 April 2013 (UTC)

The documentation of the template gives all the details of how the algorithm works, using pseudo-code (look at the French version of the same template, which is where it was initially written, and whose docmuementation page is more complete with test cases).
My feeling is that your implementaiton using the "//" operator does not work with negative values or with some large integers.
I warned about the various issues caused by incorrect implementation of the integer euclidian division, you should check this (this was already an issue with PHP operators used in #expr expressions. I don't know when Lua scripts were introduced and if it is really deployed on all wikimedia sites. How Lua is integrated ? Does it use also the PHP division internally or is it running its own mathematical library.
I'll get a look at what you wrote, please allow me looking at the issue more precisely. I should have been alereted much sooner, as soon as your discussion started.
verdy_p (talk) 01:14, 19 April 2013 (UTC)
Note also that my implementation also first starts by converting the moth and year together in an actual year number and month number, to take into account additions or substriction of months relatively : year*12+month gives a relative month number since some epoch, but to make computations simpler and using only positive numbers, the years and months are offsetted.
  • Example given for {{JULIANDAY|2000|03|01|12|00|00}} = 2451605 (at midday)
Convert Gregorian year and month in Roman years (starting in March 4750 BC) Yrom = (M + 9) div 12 + Y + 4751 Yrom = 6752
Mrom = (M + 9) mod 12 + 1 Mrom = 1
Convert to relative years, months and days
since March 1 in a referene year
for computing leap years correctly (since 4801 BC)
y = Yrom + 48 = (M + 9) div 12 + Y + 4799 y = 6800
m = Mrom − 1 = (M + 9) mod 12 m = 0
d = D − 1 d = 0
Effective calendar computation. Add :
  • the number of days in relative julian years (1461 days exactly every 4 years)
j = y * 1461 div 4 j = 2483700
  • the specifically-Gregorian correction on secular years,
  − y div 100   − 68
  + y div 400   + 17
  • the number of dats in past relative moths since march,
  + (m + 4) * 153 div 5 - 122   + 0
  • the number of days in the relative month,
  + d   + 0
  • and the fraction of day due to the hours, minutes and seconds, negative (before midday) or positive (after midday)
    DO NOT use integer divisions here !
  + (hour - 12) / 24 + minute / 86400 + second   + 0
Shift for the traditional Julian epoch, which starts exactly on
1 January -4712 (4713 BC) in the proleptic Julian calendat or
24 November -4713 (4714 BC) in the proleptic Gregorian calendar
JD = j - 32044 JD = 2451605
Now you can expand this formula an optimize some additions of constant offsets, but be extremely careful about the effects of euclidian divisions !!! (This was taken into account after MANY tests being performed with the limitations of the PHP "div" operator and to take into account various tricks in the #expr implementations in MediaWiki, forcing the use of some tricks).
verdy_p (talk) 01:38, 19 April 2013 (UTC)
Thanks very much for your reply, and the further info at my talk. I will fully digest all that later, but meanwhile I tried applying your above example to the problem date: year = -4800, month = 3, day = 1. I get Yrom = 0, Mrom = 0, y = 0, m = 0, d = 0. Those values give j = 0 and JD = -32044. That is the same as the result from the above script. However, the template gets -32410 for the same date. Consider:
{{JULIANDAY|-4800|3|1}} → -32410 (script gives -32044)
{{JULIANDAY|-4800|3|31}} → -32380 (script gives -32014)
{{JULIANDAY|-4800|4|1}} → -32014 (script gives -32013)
Could the template have a problem for the first month or two? Johnuniq (talk) 03:34, 19 April 2013 (UTC)
This could be now a problem of the template (there has been some recent changes on how the #expr operators mod and floor() are implemented, and this could introduce an incompatibility for some negative values, even though I took care of avoiding all negative numbers using the start date in March -4800). verdy_p (talk) 03:41, 19 April 2013 (UTC)
Note: the template is NOT returning valid values in year -4800 because it is outside its expected range (year -4800 is 4801BC...). Not a problem of the template as documented, but here we fall on the limitation of the PHP "div" operator which is not returning the mathematical floor() on negative values but the ceil().
So there was no bug, and your tests in LUA are also valid but do"nt have this limitation (the #expr implementation does not use any tests for negative dividends, in order to decrement its result, to save some expansions on "reasonnable" dates; this was really documented).
So no warranty in the result in the existing template before March 4800BC (i.e.{{JULIANDAY|-4799|3|1}}).
The current template could have been written equivalently (without more complexity) using a starting date 4800 years before, i.e. in March 9600 BC, just requiring to adjust the value of the constant substracted at end. It would still not solve the problem of negative numbers with the PHP "div" operator which truncates towards zero and does not floor() the result towards minus infinity (the only fix possible in the template would have been to test negative values to increment the result of the mod operator conditionally, but this would have largely increased the complexity of template expansions).
The template was written only to avoid all tests and reduce the number of parameter expansions to their maximum, for performance reasons (before the Lua extension was added, to replace #expr that still does not supports temporary local variables)
Note that this limtiation of "mod" was part of a now very old bug reported and longly discussed on MediaWiki's Bugzilla, about the limitations of "mod", and also "round 0" which is less limited (but both are truncating towards zero); at that time there was also still no support in #expr for floor(), which solves the problem cleanly, just like what you wanted to write in Lua ; in other words, the Lua extension is not needed for JULIANDAY: using floor() in #expr would now solve its limitations. But there was no bug as my template largely improved the template expansions, and largely improved the computation of date down to far dates in the past starting in March 4800 BC, and up to very far dates in the future, for almost all practical use cases of dates in Wikipedia). verdy_p (talk) 03:54, 19 April 2013 (UTC)

Hi! Thanks for the input! Could you also add the "dateOfJulianDay" function to Module:Sandbox/DixonD/Datetime/Julian so that we have the same set of functions for both calendars? --DixonD (talk) 06:43, 19 April 2013 (UTC)

I took the liberty to modify your implementation and sandbox, and I expected to add the same conversion to the Julian calendar. But I have still not written the test cases for the Gregorian conversion (may be you can write it, so I can fix bugs).
I have also fixed the English documentation of the JULIANDAY template to exhibit and explain the limitations. I have also commented your Gregorian test cases where the differences are expected (I have already explained you the reason).
Note that the existing Template can be fixed without even using a Lua module (it just consists in using floor() whose support was added to #expr much longer after the template was written by me, or the more recent addition of fmod which could also save some parameter expansions. With this fix, it will no longer be necessary to use Lua at all as he parameter expansion will be completely equivalent (and even less complex than with using Lua which will first require to convert the individual template parameter using {{#if:{{{1|}}|{{#expr:{{{1|}}}}}|}} or {{#expr:{{{1|default value}}}}} before passing their returned value to the Lua module).
verdy_p (talk) 06:51, 19 April 2013 (UTC)
No, evaluating of expressions is already done in the module by calling "_cleanNumber" from Module:Math. I've added a test "2000+6|6-1|1" to demonstrate it. See the results of the updated tests.
My main motivation to convert that functionality to Lua was not to overcome some limitations (but it is good if we can do this as well), but to gather all dates-computing functionality in one place and probably improve performance (if I know how to measure it...) --DixonD (talk) 07:12, 19 April 2013 (UTC)

I've added tests for "yearOfJulianDay" and some tests don't match with current template. The most important is for 1721060, where the current template returns "-1" oppose to "0" from Lua. Can you have a look? --DixonD (talk) 07:38, 19 April 2013 (UTC).

I've investigated the case, and my implementation in Lua is correct, the limitations is within the existing template that fails on 1721060 which is the correct value for {{JULIANDAY|0|1|1}} and for which {{JULIANDAY.YEAR|1721060}} currently returns -1 instead of 0 due to its (old) use of the limited/buffy "mod" or "round 0" operator that truncate towards 0 instead of towards minus infinity. Here also, using "floor()" in the template would fix it easily.
For now the Lua code gives the correct results in all test cases, and the JULIANDAY.YEAR template will fail in negative Gregorian years. I'll fix it easily in the French Wikipedia from which the templates were initially developed and imported to the English Wikipedia, using more test cases (it is simple to do even without using Lua modules). For now the English template does not work with negative proleptic Gregorian years, and I'll document it.
In fact, all the existing calendar templates based on "round 0" or "mod" in #expr are affected by these limitations of valid value ranges. They should all use "floor()" instead. verdy_p (talk) 12:26, 19 April 2013 (UTC)

I've moved testcases to Module:Sandbox/DixonD/DateTemplates/testcases in case you are looking for them. Thanks a lot for you work and fixes. Can I ask you one more thing? I mean "dateOfJulianDay" function to Module:Sandbox/DixonD/Datetime/Julian. Once we have it, we will have more or less consistent version of date modules which may be used to code a bunch of templates in Module:Sandbox/DixonD/DateTemplates. --DixonD (talk) 20:27, 19 April 2013 (UTC)

246 links...[edit]

... to disambiguation pages on Meteorite fall. Nice one! The Banner talk 01:31, 29 August 2013 (UTC) This is the People Front Against Links To Disambiguation Pages. Fix it or we shall put salt in your tea and coffee!

I know that, but before there was no link at all, I'm already fixing them by looking for redirects, and disambiguation pages, and individual sources to confirm the locations...
Note that the first column lists the meteorite name, which most often is a name of a location, but most of them don't have any specific article, and I point to the relevant ciy.
It's quite normal to have many disambiguations, and even before you posted it, I was already working on them (if you had looked at the page history).
There's no other way than checking them one by one, and testing each link, given the length of this list, which also contained LOTS of typos that I correct as well! verdy_p (talk) 01:36, 29 August 2013 (UTC)
Sounds you are i need for Wikipedia:WPCleaner! The Banner talk 02:23, 29 August 2013 (UTC)
==Disambiguation link notification for August 29==

Hi. Thank you for your recent edits. Wikipedia appreciates your help. We noticed though that you've added some links pointing to disambiguation pages. Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ • Join us at the DPL WikiProject.

Meteorite fall (check to confirm | fix with Dab solver)
added links pointing to Saint Louis, Andover, Apt, Gifu, Sioux County, Phillips County, Monahans, Harrison County, Sainte-Marguerite, Magnesia, Wethersfield, Plantersville, Nagai, Ash Shamaliyah, Bald Mountain, Kangean, Villarrica, Modoc, Saint-Robert, Omnogovi, Saint-Mesmin, Lanxi, Mafra and Pricetown

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 11:19, 29 August 2013 (UTC)

I don't need two alerts for the same edit...verdy_p (talk) 11:39, 29 August 2013 (UTC)
The second one was by a bot. Last score mentioned the number as 208, so we make progress. Especially because I fixed a few after that measurement. The Banner talk 13:37, 29 August 2013 (UTC)
Thanks but I fixed much more before, in preexisting links of the page, even if I added many links to try disambiguating a lot of locations. Long lists of toponyms without links are boring, we don't know what it speaks about or when the name was taken or from which language or orthography and this list mixes names from many epochs. All this requires disambiguation, even in absence of links. I've already fixed hundreds (with or without links) in this page. verdy_p (talk) 13:51, 29 August 2013 (UTC)
Sad, I thought we were making enormous progress. Than I found some edits of Xezbeth: 100 links done, 100 links wrong. Still, we are making progress. Last count is 187. The Banner talk 22:53, 29 August 2013 (UTC)

Help with Template:Random number[edit]

Hi :) Is there any chance you could drop by Template_talk:Random_number#Caching_has_killed_this_template and give your thoughts as to why that template is basically wholly broken now? Any advice about how to make that template work again would be greatly appreciated. CzechOut | 19:49, 21 October 2013 (UTC)

I replied, and made the sandbox test.. verdy_p (talk) 11:30, 22 October 2013 (UTC)

Category:Northern America[edit]

Category:Northern America, which you created, has been nominated for possible deletion, merging, or renaming. If you would like to participate in the discussion, you are invited to add your comments at the category's entry on the Categories for discussion page. Thank you. Obi-Wan Kenobi (talk) 00:33, 15 November 2013 (UTC)

Category:Northern American culture[edit]

Category:Northern American culture, which you created, has been nominated for possible deletion, merging, or renaming. If you would like to participate in the discussion, you are invited to add your comments at the category's entry on the Categories for discussion page. Thank you. Obi-Wan Kenobi (talk) 00:34, 15 November 2013 (UTC)

Disambiguation link notification for February 1[edit]

Hi. Thank you for your recent edits. Wikipedia appreciates your help. We noticed though that when you edited Armenian alphabet, you added a link pointing to the disambiguation page Emphasis (check to confirm | fix with Dab solver). Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. Read the FAQ • Join us at the DPL WikiProject.

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, DPL bot (talk) 09:15, 1 February 2014 (UTC)

February 2014[edit]

Hello, I'm BracketBot. I have automatically detected that your edit to Romanization of Armenian may have broken the syntax by modifying 1 "()"s. If you have, don't worry: just edit the page again to fix it. If I misunderstood what happened, or if you have any questions, you can leave a message on my operator's talk page.

List of unpaired brackets remaining on the page:
  • backquote ` U+0060, or the ASCII apostrophe-quote ' U+0027 when there was no confusion possible).
  • mark|left single quotation mark]] U+201B used to replace the ambiguous ASCII apostrophe-quote). U+02BD can also be used within documents prepared for fine Armenian typography because the

Thanks, BracketBot (talk) 07:27, 3 February 2014 (UTC)

BAD DETECTION, the characters are used on purpose !!! Your bot does not read and ũnderstand the text. verdy_p (talk) 07:31, 3 February 2014 (UTC)

Articles you might like to edit, from SuggestBot[edit]

SuggestBot predicts that you will enjoy editing some of these articles. Have fun!

Add sources
Glossary of BitTorrent terms
Gradius (video game)
Onasagorou Street
Konami
Super Contra
El Aaiún
Cleanup
Contra: Hard Corps
Boktai: The Sun Is in Your Hand
Delete key
Expand
Operation C
Hard Corps: Uprising
Baraigram Upazila
Unencyclopaedic
Union of Brittany and France
Blades of Steel
Platform game
Wikify
Texas French Symposium
Shape moiré
BitTorrent (company)
Orphan
Långhalsen
Raipara Upazila
Shah Makdam Upazila
Merge
Sandwip Upazila
Cantonment Thana
Polish alphabet
Stub
El Marsa, Western Sahara
Boujdour Province
Nesarabad (Swarupkati) Upazila
Phalerum
Pirojpur Sadar Upazila
Scribes (software)

SuggestBot picks articles in a number of ways based on other articles you've edited, including straight text similarity, following wikilinks, and matching your editing patterns against those of other Wikipedians. It tries to recommend only articles that other Wikipedians have marked as needing work. Your contributions make Wikipedia better — thanks for helping.

If you have feedback on how to make SuggestBot better, please tell me on SuggestBot's talk page. Thanks from Nettrom (talk), SuggestBot's caretaker. -- SuggestBot (talk) 04:18, 15 May 2014 (UTC)