Misplaced Pages

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

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 Misplaced Pages'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 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

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

Welcome to Misplaced Pages. Everyone is welcome to contribute to the encyclopedia, but

I am NOT new to this Misplaced Pages... 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 Misplaced Pages: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

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

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 ). 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

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 _―Œ 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 _―Œ 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 _―Œ 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 _―Œ 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

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

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

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 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, Misplaced Pages 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

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

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

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 { 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

Your edit http://en.wikipedia.org/search/?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 (talk • contribs) 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

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

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

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

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

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

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

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

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

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

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

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

Sans-serif IPA fonts

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

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-Seitzfu-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-Seitzfu-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

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.

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

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)

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 Misplaced Pages). 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 Misplaced Pages from which the templates were initially developed and imported to the English Misplaced Pages, 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...

... 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 Misplaced Pages:WPCleaner! The Banner talk 02:23, 29 August 2013 (UTC)

==Disambiguation link notification for August 29==

Hi. Thank you for your recent edits. Misplaced Pages 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

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

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

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

Hi. Thank you for your recent edits. Misplaced Pages 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

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)