Wiktionary

Wiktionary talk:Per-browser preferences

Latest comment: 1 year ago by 146.199.34.139 in topic BCE/CE to BC/AD Setting Not Behaving Correctly

Documentation edit

Procedure for adding stuff edit

Latest comment: 17 years ago1 comment1 person in discussion
  1. In User:Connel MacKenzie/custom.js add the magic .CSS code in the first section.
  2. In the lower section, add a "button" (it adds a checkbox to the preferences page)
  3. In the User:Connel MacKenzie/Preferences#Preview/test section, add a test that demonstrates the change. Did away with this, a long time ago.

Have fun!

--Connel MacKenzie 00:30, 18 January 2007 (UTC)Reply

Discussion edit

Rewording, moving stuff around edit

Latest comment: 17 years ago2 comments1 person in discussion

I can't believe no one ever reworded some of the more outrageous items. Part of the reason I worded things so oddly, was to encourage others to help out with maintaining it...but that hasn't really worked so well, so far. If someone is willing to give it some real thought, these could probably be reordered much more logically, instead of in the order they were implemented. --Connel MacKenzie 00:33, 18 January 2007 (UTC)Reply

Also, do people have ideas on how to clean up "custom.js"? Right now, the 1st half is the customizations, the second half is the thing that does the magic checkboxes on this page. You can reorder the buttons in the second half to your heart's content, without changing the cookie names. The order they are added is the order they appear. --Connel MacKenzie 01:21, 18 January 2007 (UTC)Reply

SPELLING MISTAKE edit

Latest comment: 17 years ago1 comment1 person in discussion

Obviously I can't edit the project page Wiktionary talk:Preferences replace horizonatal with horizontal BrenOnt 22:51, 22 April 2007 (UTC)Reply

split the page up edit

Latest comment: 16 years ago1 comment1 person in discussion

Would it be advisable to clearly demarcate which options are for all users and which just for editors?—msh210℠ 21:36, 20 February 2008 (UTC)Reply

Nothing in Safari edit

Latest comment: 15 years ago11 comments3 people in discussion

I'm pretty sure WT:PREFS used to work for me. Now nothing shows up between “Save settings to refresh view” and the category links.

I do see the prefs in Firefox 3, but what I set there doesn't take effect in the other browser. —Michael Z. 2008-08-11 20:52 z

I learned that clearing the cookie restores the unfilled preferences form, but any time I check some prefs and click “Save settings” once or twice, the entire form disappears and none of the prefs work. Currently using Safari 3.2.1/Mac. —Michael Z. 2008-12-02 18:02 z
Does Safari have any sort of "error console" to see if maybe the JavaScript is raising/throwing an exception/error/something? That would explain the form disappearing — the checkboxes are added by JavaScript (User:Connel MacKenzie/custom.js) — so if a [something] occurs before the first checkbox is added to the DOM, the script would exit and none of them would show up. —RuakhTALK 19:42, 2 December 2008 (UTC)Reply
Not sure where I would look for an "error console", but I use Safari and have the same problem. I originally set my PREFS while using a PC, so I can't recall whether this is a "new" problem (within the past year), or whether I've just never adjusted preferences from my Mac until recently. --EncycloPetey 19:48, 2 December 2008 (UTC)Reply
It's hard to be sure without actually trying it out myself, but it looks like item #14 of the Safari Developer FAQ (http://developer.apple.com/internet/safari/faq.html) describes what I'm looking for. Can you give it a try? —RuakhTALK 19:53, 2 December 2008 (UTC)Reply
OK, I've deciphered the info... Interesting. Opening this edit window produced this error message:
Visiting WT:PREFS yields no message (cause it's a redirect?), but then reloading yields two error messages:
That, at least, looks specific enough to be addressed. --EncycloPetey 20:08, 2 December 2008 (UTC)Reply
The error about <style> inside <div> is fine, firstly in that (judging from the message) Safari seems to be handling it properly, secondly in that it doesn't seem like it can be the source of the problem, and thirdly in that there's nothing we can do about it anyway. (That error is due to the site notice, which is currently a fundraising box that does indeed have a <style> within a <div>.)
The DOM exception is interesting. I can't replicate it on Safari on Windows, but Google suggests that it may be Mac-specific in some cases, which would explain that. The problem is, while in theory I think we could fix it by just using appendChild instead of innerHTML, I'm worried that that would break IE support. :-/   But oddly, that doesn't seem like it should affect WT:PREFS, either, so mostly I'm just at a loss.
—RuakhTALK 02:30, 3 December 2008 (UTC)Reply
O.K., duh, I do see how that would affect WT:PREFS. I've now edited MediaWiki:Common.js in a way that should hopefully fix it without breaking support in any other browsers. Please hard-refresh and try again. —RuakhTALK 14:33, 3 December 2008 (UTC)Reply
Change looks good to me - such is the fun of the DOM. Conrad.Irwin 14:43, 3 December 2008 (UTC)Reply
Well, I just tried it yet again (to see what the console says), and the “Trial the javascript prominent interwiki links” actually added the link to a page once. I reloaded, and it was gone again (although the WT:PREFS form is still there). I doubt this helps much. By the way, I ran the contents of User:Connel MacKenzie/custom.js through a couple of online JavaScript Lint checkers, and it threw a whole bunch of error messages, mostly about missing braces. —Michael Z. 2008-12-02 20:14 z
It's popping in and out for me. It seems the links appear if I load a page орел, but not if I load a URL with page anchor орел#Ukrainian. Caching seems to confuse this distinction, but a page reload always acts as described. —Michael Z. 2008-12-02 22:45 z
Hm, that's very interesting - I had a problem with User:Conrad.Irwin/parser.js when visiting links with a # in them. The lint checking is just complaining that I didn't explicitly use {} around single statement blocks (which is a perfectly valid thing to do). Conrad.Irwin 14:43, 3 December 2008 (UTC)Reply
Okay, I'm not making this up: now the link shows up whenever I load any version of a URL: ковбаса, ковбаса#Ukrainian, or ковбаса#fake. But on every single reload of such a page, it is gone. Load from URL again, there, reload, gone. No matter how many times or in what combination. Safari/Mac only; works as advertised in Firefox/Mac. —Michael Z. 2008-12-03 15:16 z
I'm guessing that when you explicitly reload the page, Safari does a hard-refresh, dumping all referenced resources from its cache. Then it has to actually re-download all the scripts in order to import them. Further, I'm guessing there's some sort of race condition, such that if there's a delay during the import process (e.g. due to having to re-download them), they won't all work. If so, it's probably fixable, but probably not by me. I just don't know enough about browser and JavaScript quirks and such. Sorry. :-/   —RuakhTALK 16:12, 3 December 2008 (UTC)Reply
Race condition is possible, and should be fixable if we can find it (note [1] means that all added hooks will run, [2] means there shouldn't be a race condition after iwiki.js has started) though I'm not sure how to start looking as I'm also Safari-less. Conrad.Irwin 16:20, 3 December 2008 (UTC)Reply
Safari has just come out in a new version 3.2.1. When I updated my version a few minutes ago, some of the previous problems were corrected, including the WT:PREFS issue. Ruakh's style/div edit may be responsible as well, since I did not try the page between the time he made his edit and the time I updated. --EncycloPetey 19:30, 4 December 2008 (UTC)Reply
WT:Prefs seems to be working for me now, but the interlanguage link still disappears on reload (the possible race condition described above). —Michael Z. 2008-12-07 23:11 z

Move to Gadgets tab in Special:Preferences ? edit

Latest comment: 13 years ago15 comments6 people in discussion

Could this function please be moved into the Gadgets tab in Special:Preferences? That way, it would be portable from browser to browser, and computer to computer, without having to retain cookies on a local computer to use it? Cirt 22:08, 6 December 2008 (UTC)Reply

We do have Gadgets installed, so that should be possible. However:
  • I'm not sure whether we want to do it for all preferences, because:
    1. some users might well prefer certain preferences only on certain browsers (e.g. the IRC link, the spellchecker, and the inflection-boxes).
    2. the Gadgets tab seems a bit formal, and a lot of these preferences aren't very functional.
  • None of our preferences are in appropriately-named files, so this would take some effort.
  • Since gadgets are loaded before the site skin, whereas these preferences are loaded afterward (I think?), we'd want to do some debugging to make sure that all preferences work as gadgets.
All told, I'm not opposed, but I think it warrants discussing at Wiktionary:Grease pit, or even at Wiktionary:Beer parlour, before anyone starts along that route.
—RuakhTALK 23:27, 6 December 2008 (UTC)Reply
Okay these all sounds like good points. Perhaps post a note to Wiktionary:Grease pit, or Wiktionary:Beer parlour, that way we could keep a unified discussion here? Cirt (talk) 01:39, 7 December 2008 (UTC)Reply

Update: I posted a notice about this thread, in a new subsection at Wiktionary:Beer parlour. Cirt (talk) 07:15, 7 December 2008 (UTC)Reply

Special:Preferences should only include items that are debugged and at least working in the modern browsers (Firefox, Safari, Opera), and hopefully in MSIE too. I'd rather not see it cluttered with about 40 unsorted and undocumented preference items. Is there a way to gauge how much use which of the preferences are seeing?

By the way, is Gadgets supposed to be enabled now? I don't see the tab in my special:Preferences. —Michael Z. 2008-12-07 23:00 z

Gadgets is enabled, and we don't use it for a few reasons. Firstly many of the WT:PREFS are CSS based, and adding an entire javascript file for each one line of CSS is very inefficient. Secondly it would prevent anonymous users from using them. Thirdly it'd need someone with some time on their hands to port everything across and check that it worked everywhere (and as we just got PREFS working again in safari, it'd probably irritate many people to re-break things). The benefit of Gadgets is that prefs are tied to a user instead of a browser, so they are carried between computers (though this can cause a problem with browser-specific prefs) - but that's not a huge benefit. I'd been thinking vaguely about finding a way to store WT:PREFS for logged in users in the way gadgets does, but haven't had time to look into how to hack the mechanism. There's no way of counting PREFS usage - though it could be done with a few minutes of work and a toolserver account and a wait of a month [yay cache] - if there were no privacy concerns. We could really do with a new interface page, I recently cleaned up all of the code, but the list of tick boxes could do with a sorting. Conrad.Irwin 00:34, 8 December 2008 (UTC)Reply
It would be nice to document them, too—I can't tell what some of them do. I'll start a list above, and let those in the know fill in any gaps.
This could be a good start to sorting and categorizing them, and designing a friendlier interface. Is there any impediment to adding a label element with title attribute for each checkbox? —Michael Z. 2008-12-08 01:14 z
I've put them into broad categories, if you want to do more just poke at User:Connel MacKenzie/custom.js - you could get it to add a label instead of just text for each item by editing function wiktAddButton. Conrad.Irwin 00:35, 9 December 2008 (UTC)Reply
Re: CSS-based PREFS: My understanding from reading the docs was that gadgets could be CSS, JS, or both. Did I misunderstand? —RuakhTALK 02:18, 8 December 2008 (UTC)Reply
Gadgets can be CSS, JS, or both - Ruakh (talk • contribs) is absolutely correct on this. And yeah, the major advantage is portability by user to any browser, as opposed to having to reset preferences every time you go to a new computer/browser. Cirt (talk) 05:33, 8 December 2008 (UTC)Reply
In reply to Conrad's "I'd been thinking vaguely about finding a way to store WT:PREFS for logged in users in the way gadgets does, but haven't had time to look into how to hack the mechanism": What I do is simple: I choose the (few) prefs I want to use and edit special:mypage/monobook.js. User:Msh210/monobook.js thus has importScript calls for Conrad's creation.js, Connel's patrolled.js, and others, and has my own version of Connel's reformat.js.—msh210℠ 20:29, 8 December 2008 (UTC)Reply
Msh210 (talk • contribs) does also bring up a good point, perhaps we should have a page explaining how to do this for newer users? Cirt (talk) 23:26, 8 December 2008 (UTC)Reply
I'd add it under #Documentation above, but it's not a trivial task - which is why some auto-solution would be better, saving it in user javascript is a possibility I've had a look at, it should be fine but the effects of mistakes could be considerable for an automaton editing source code. Conrad.Irwin 00:35, 9 December 2008 (UTC)Reply
Well that is why only admins can edit that part of project-space. :) Cirt (talk) 00:48, 9 December 2008 (UTC)Reply
I'd like to start by saying that in general, I think this is a good direction. I'm confused by some of the comments above from Michael Z regarding documentation. At any rate, several attempts to unify and reset all the JS have come and gone (most memorably to me, on Brion's Wiktionary test server.) Refactoring it all, seems like the correct first step. As parts can be separated out without losing efficiency (i.e. not crashing anyone) they can and should be migrated to Gadgets. But a keen eye should be kept on that total JS size, since it is reloaded so frequently (except each time the devs try to add performance enhancements that obliterate functionality and is invariably undone quickly.) Before Gadgets, the intent was to move all site-specific JS to the Wiktionary namespace. I know I did not follow through with that, even though others have done sporadic maintenance. If anyone is (or better, a group of people are) considering taking this on, I hope they solicit input from other language Wiktionaries. Off the top of my head, BS, DE, FR, NL, AR, ZH, JA and others have very significant JS investment as well. --Connel MacKenzie 03:57, 9 December 2008 (UTC)Reply
Re: documentation, I've gone through the code and I think I've figured out most of the puzzling ones. For example, “Allow special characters to be input” meant to display another copy of the wiki character picker (this is something I routinely do with my system's keyboard layouts and character pallette)—special characters have always been “allowed”. “Indent entries with “See also” lines above the TOC properly” actually means to indent the “see also” by 4 ems instead of 2 ems—“propriety” has nothing to do with it, and why do we need to clutter the prefs and provide software support for this?
I have a problem with the huge investment here in truly trivial functionality. Offering someone the opportunity to italicize their brackets doesn't only bring down the prefs interface by filling it with dreck, it also introduces a maintenance burden and a threshold of accessibility to developers. It weaves code through dozens of inflection templates whose function is to put redundant content into every entry in the project, and then more code in the CSS to hide some of it from those of us who don't rely on assistive technologies (if you dropped a few grand on a braille display which actually follows web standards, then screw you, because you'll have to read inflections twice and will have to read transliterated terms with nonsensical brackets).
WT:PREFS should be pared down. We should just pick a design for minor typographical elements instead of bringing down the whole project in the name of meaningless “user choices.” And trivial nonsense shouldn't be introduced into the main prefs.
Sorry to rant, but I've spent a lot of time wading through the infrastructure, trying to figure out how to make meaningful improvements, and I am forming a worrying picture. —Michael Z. 2008-12-09 21:11 z
As you may have noticed with the script templates, people love to complain about trivial details. Having the ability to customise things that people love to argue about prevents such arguments. While I'd be happy to hide all the really trivial ones in a [show] box, it'd cause more political hassle than it should to remove them completely. Conrad.Irwin 21:21, 9 December 2008 (UTC)Reply
Sure, let's call it “Advanced preferences”.
But I am also really concerned about the pervasive baggage that some of these checkboxes are wired up to. (see Wiktionary:Grease pit#Misuse of markup and CSS).
And I understand the need to avoid arguments and to compromise. But if the project is unable say “no” to someone who absolutely needs to be able to change their brackets from roman to italic and back, then what will it look like in a year, or in ten? —Michael Z. 2008-12-10 01:43 z

Proposal to migrate into a user scripts library edit

It looks like at this point most of the well-vetted scripts have been migrated into Gadgets, so the system here is basically redundant. In addition, it adds JS overhead to every page load regardless of whether a person is using it or not. I would like to propose that this page be migrated into a directory of user scripts that people can install in their user script files (similar to w:Wikipedia:WikiProject_User_scripts/Scripts). That way all of the scripts are still available, but there won't be two different systems for using them automatically. Kaldari 00:04, 1 April 2011 (UTC)Reply

Layout edit

Latest comment: 15 years ago1 comment1 person in discussion

Woops, I had just started playing around with the layout, and I notice that I'm not the only one. Please see my in-progress draft: Wiktionary_Preferences. —Michael Z. 2008-12-09 04:43 z

I realize that this can't be accomplished without revising the current page-drawing mechanism.

I suggest that the “Save settings” link at the top be changed to a submit button at the bottom, which also refreshes the page after it updates the cookie. This will let the user feel like they're actually changing something, and give instant feedback by changing the page (e.g., adding the IRC link which they expected to have activated). —Michael Z. 2008-12-09 04:46 z

Sounds good. —RuakhTALK 19:42, 9 December 2008 (UTC)Reply

Controls don't work edit

The following don't work at all in my Safari 3.2.1/Mac and Firefox 3.0.4/Mac:

  • Put the [show] button onto the left of the translation bars
  • Hide the horizontal separator between each language section

Since no one is complaining, why not just remove them? —Michael Z. 2008-12-09 19:02 z

Labels edit

Latest comment: 15 years ago2 comments1 person in discussion

I believe that text labels can be added by changing the line in User:Connel_MacKenzie/custom.js 

      var text = document.createTextNode( speedTip );

to the following: 

      var text = document.createTextNode( "label" );
      text.setAttribute( 'for', cookieToToggle );
      text.appendChild( document.createTextNode( speedTip ));

This would let users click the entire labelled control to toggle. Not tested yet. —Michael Z. 2008-12-10 19:53 z

The concept sounds good. I haven't tested either, but I imagine you'd also need a line like
      checkbox.id = cookieToToggle;
(since it's <label for="element_id">, not <label for="element_name">). And if we want to be paranoid about avoiding duplicate ids, we might want to prepend "wiktpref_" or something (though it's probably fine even without that).
—RuakhTALK 21:20, 10 December 2008 (UTC)Reply
Every name attribute already starts with “Wikt...” (including WiktPref..., Wiktionary..., and WiktionaryPreferences...). I believe the IDs should match the names.
The only similar ID I have found is Wiktionaries_in_other_languages, used on the main page. —Michael Z. 2008-12-11 17:42 z
Then if there's no objection, I'll add the IDs and labels to the code. Is there a page where our IDs and classes are documented, to prevent conflicts? —Michael Z. 2008-12-17 15:49 z
Re: "Is there a page where our IDs and classes are documented, to prevent conflicts?": Yup. It's linked to from our JS&CSS coding guidelines and best practices page, as well as from our comprehensive, up-to-date list of policies.   Which is to say: no, but feel free to start one. —RuakhTALK 03:35, 19 December 2008 (UTC)Reply


Edit link edit

Latest comment: 14 years ago1 comment1 person in discussion

The first line says, "On this page, you can set your browser-specific English Wiktionary preferences", followed by an edit-link to User:Connel MacKenzie/custom.js, which normal users cannot edit. This is, well, confusing to say the least. I would suggest that the link to edit the latter page either be removed from this page entirely or placed somewhere less obvious to normal users (like at the bottom, following a brief explanation of what the link is for). - dcljr 22:44, 1 October 2009 (UTC)Reply

What a sad page edit

Latest comment: 14 years ago4 comments4 people in discussion

If you don't have JavaScript turned on, you get nothing. You don't even get told you need it.

Also, use the <label> tag so we can click them like proper system checkboxes instead of having to poke at the squares. 89.100.67.231 02:25, 3 November 2009 (UTC)Reply

I agree with the anonymous... The warning is not shown when I disable javascript, and the label would help a lot! Helder 19:16, 6 November 2009 (UTC)Reply
Thanks! I've fixed both issues. (Note: for the <label>s to work, you'll have to either visit <http://en.wiktionary.org/w/index.php?title=User%3AHippietrail%2Fcustom.js&action=raw&ctype=text/javascript&dontcountme=s> and click "refresh", or else wait up to a month for all the relevant caches to clear.) —RuakhTALK 16:53, 7 November 2009 (UTC)Reply
It's still pretty horrible that code. It was originally made by Connel Mackenzie who did lots of useful things but in very hacky ways. Conrad Irwin and myself (Hippietrail) have worked on it a little since then but there's still lots of legacy hack. It should be moved out of my space into MediaWiki: or Wiktionary: now that I haven't been actively working on it for some time. — hippietrail 02:25, 10 November 2009 (UTC)Reply

wikipedia : user:hopiakuta/_wiktionary:preferences_&_special:preferences_preference edit

Latest comment: 14 years ago1 comment1 person in discussion
  • I have searched one by one in order to locate what seems to be the most severe problem; have you had a similar experience?
  • This discussionpage includes several malfunctions, including that I had to escape in order to get it to load; then, I had to function eleven in order to see the edit window,......
  • * * * The worst page on this website.

hopiakuta DonFphrnqTaub Persina 10:30, 19 November 2009 (UTC)Reply

Bug edit

Latest comment: 13 years ago2 comments2 people in discussion

The "Change the bullets in unordered lists to be round." pref and any prefs added to the end don't seem to be able to save properly. --Yair rand (talk) 06:07, 23 July 2010 (UTC)Reply

Fixed a bit ago. --Bequw → τ 05:27, 8 August 2010 (UTC)Reply

Rename edit

Latest comment: 13 years ago9 comments3 people in discussion

Would anyone object to renaming this page something like WT:Browser-specific preferences so as to avoid the Wiktionary:Preferences / Special:Preferences confusion? --Bequw → τ 05:29, 8 August 2010 (UTC)Reply

renaming may be wise, for the reason stated, but "browser-specific preferences" sounds to me more as though they will only work in certain browsers than as though they will only work in the browser in which they were set. (The former is true, too, but is not what's meant, I don't think.) "Wiktionary:Preferences (stored in your Web browser)" is clearer but highly unwieldy.​—msh210℠ (talk) 15:04, 9 August 2010 (UTC)Reply
Maybe Wiktionary:Cookie-based preferences? —RuakhTALK 15:15, 9 August 2010 (UTC)Reply
Sounds good for users who know what the tech term means. I worry that many non-techy users have heard of cookies, don't (or perhaps even do) know what they are, and have very negative associations with them ("this is a way for the Web site to track what I'm doing!") that may prevent them from using a page titled that way. But perhaps people who might use it if less scarily-titled are of the sort to know not to be scared by such a title.​—msh210℠ (talk) 16:25, 9 August 2010 (UTC)Reply
Well, we could take a page from the relevant RFCs: Wiktionary:HTTP-state-management-mechanism-based preferences. ;-)   —RuakhTALK 17:17, 9 August 2010 (UTC)Reply
What about Per-browser preferences? --Bequw → τ 20:18, 9 August 2010 (UTC)Reply
Good IMO. Though "HTTP-state-management-mechanism-based preferences" has a nicer ring to it....​—msh210℠ (talk) 20:37, 9 August 2010 (UTC)Reply
By the way, the current texts atop the page describe this as "your browser-specific {{{{CONTENTLANGUAGE}}}} Wiktionary preferences". If we rename the page to use "per-browser" or something else, then we should probably change those texts similarly. (Of course, the page-text can be longer and have more explanation than the page-title.) —RuakhTALK 14:39, 10 August 2010 (UTC)Reply
Renamed. What's wrong with the current text? Do you have a problem with the {{{{CONTENTLANGUAGE}}}} or that the title says "per-browser" and the text says "browser-specific"? --Bequw → τ 20:29, 10 August 2010 (UTC)Reply

Template:q edit

Latest comment: 13 years ago1 comment1 person in discussion

Has been deleted. So that line has to be removed. Mglovesfun (talk) 10:04, 10 January 2011 (UTC)Reply

Alternative edit

Latest comment: 12 years ago1 comment1 person in discussion

Shouldn't most users technically be able to replace PREFS functionality with Greasemonkey scripts? I'm not sure of exactly how to translate a script referenced here to the Greasemonkey paradigm, but Greasemonkey scripts can be installed for FF, Chrome, Safari, IE, and Opera browsers. Only mobile browsers and people with locked down machines should be unable to do this. --Bequw → τ 13:38, 19 July 2011 (UTC)Reply

Broken in March 2014? edit

Latest comment: 10 years ago4 comments2 people in discussion

I don't believe I've changed any browser settings for months or years but this page now comes up blank for me.

I came here because cirwin's automated translation adder has also not been working for me for a couple of days. — hippietrail (talk) 06:20, 20 March 2014 (UTC)Reply

I don’t know why that would be. I’m using the latest Firefox and I see everything fine. Try logging out and see if you see it. —Stephen (Talk) 06:28, 20 March 2014 (UTC)Reply
I'm on the latest Google Chrome on 32-bit Windows 7 Starter. Logging out and in didn't change it. Turning on the debug console results in this error:
Uncaught Error: Unknown dependency: ext.vector.collapsibleNav
— hippietrail (talk) 14:40, 22 March 2014 (UTC)Reply
Aha but staying logged out does fix it. I'm guessing some change interacted with what was already in my personal JS since I haven't changed that stuff in at least one year. — hippietrail (talk) 14:43, 22 March 2014 (UTC)Reply

BCE/CE to BC/AD Setting Not Behaving Correctly edit

Latest comment: 1 year ago1 comment1 person in discussion

I just decided to try out the BCE/CE to BC/AD setting, but it appears to not be working properly. On the page I was reading it changed C.E. to BC, which is obviously incorrect: 600 C.E. should become AD 600 (or simply 600). This is very disappointing, as I was looking forward to not having to deal with the unfamiliar notation.

(I am using the latest version of Firefox if that's relevant, though I suspect it's simply a bug with whatever script implements the setting.)

— 146.199.34.139 12:52, 23 August 2022 (UTC)Reply

Add topic
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary_talk:Per-browser_preferences&oldid=76211773"
Return to the project page "Per-browser preferences".