User talk:Drmccreedy

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

SVG Images[edit]

Hello. I used CorelDRAW X4. The steps are:

  • ctrl+N to create new blank file.
  • layout --> page setup; edit the size, unit (I prefered to choose pixel), resolution, etc.
  • click text tool, and type the text. you can easily resize it.
  • file --> export. I usualy use default setting (which appear when you're about to export the SVG), except for "presets" I chose "Text as curves PNG image", and Bitmap export type is PNG. I also choose "link images".
  • thats all, and I hope you try it easily as I did.

M. Adiputra (talk) 02:08, 15 April 2011 (UTC)

I created with these steps, above, and didnt create it by .png or convert any .png. That's all. M. Adiputra (talk) 02:51, 17 April 2011 (UTC)
The result is ok by using Inkscape. However I never use it. It could be an alternative for me. M. Adiputra (talk) 07:21, 25 April 2011 (UTC)

Categories for discussion nomination of Category:Unicode chart templates[edit]

Category:Unicode chart templates, 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. WOSlinker (talk) 18:37, 17 May 2011 (UTC)

unblock[edit]

Orologio rosso.svg
This blocked user's request to have autoblock on his/her IP address lifted has been reviewed by an administrator, who declined the request.
Drmccreedy (talk · contribs · deleted contribs · nuke contribs · logs · edit filter log · block user · block log)
67.6.133.4 (talk · contribs · deleted contribs · edit filter log · WHOIS · RDNS · RBLs · http · block user · block log)

Block message:

{{checkuserblock}}


Decline reason:

Please see below. AGK [•] 12:02, 12 February 2012 (UTC)
File:Orologio rosso or File:Orologio verde DOT SVG (red clock or green clock icon, from Wikimedia Commons)
This blocked user's unblock request has been reviewed by an administrator, who declined the request. Other administrators may also review this block, but should not override the decision without good reason (see the blocking policy). Do not remove this unblock review while you are blocked.

Drmccreedy (block logactive blocksglobal blocksautoblockscontribsdeleted contribsabuse filter logcreation logchange block settingsunblock)


Request reason:

All my edits are done from the same PC in my house. I do not understand why I got a CheckUser block.

Decline reason:

Whilst I think I know what IP block is affecting you, there is no block log entry for the autoblocked-IP address you specify, so we cannot investigate this. Are you sure that the information you have given is correct? AGK [•] 12:02, 12 February 2012 (UTC)

If you want to make any further unblock requests, please read the guide to appealing blocks first and then use the {{unblock}} template again. If you make too many unconvincing or disruptive unblock requests, you may be prevented from editing this page until your block has expired.

I have contacted AGK regarding this block, which was recently placed. He will get back to you shortly. --Chris (talk) 05:55, 12 February 2012 (UTC)

{{unblock }}

Sent another note to AGK; looks like some details might have been missed, the last time around? – Luna Santin (talk) 04:07, 16 February 2012 (UTC)
File:Orologio rosso or File:Orologio verde DOT SVG (red clock or green clock icon, from Wikimedia Commons)
This user's unblock request has been reviewed by an administrator, who accepted the request.

Drmccreedy (block logactive blocksglobal blocksautoblockscontribsdeleted contribsabuse filter logcreation logchange block settingsunblock)


Request reason:

Here's what I see today: Editing from 67.6.128.0/18 has been disabled by AGK for the following reason(s): CheckUser template. This block has been set to expire: 23:10, 10 March 2012. (I'm not sure why the IP address changed)

Accept reason:

I've added the IP Block Exemption (IPBE) permission to your account, so you should be able to edit as normal. Thanks for your patience, and apologies for the inconvenience. AGK [•] 00:18, 19 February 2012 (UTC)

Unblocking administrator: Please check for active autoblocks on this user after accepting the unblock request.

Ethiopic script[edit]

I wish I knew of a good source to tell you which scripts use which "extra" symbols. Even if you find a post-1991 source, it may be out of date since some language communities have switched to Roman script after initial Ethiopic script efforts. Sorry!Pete unseth (talk) 21:25, 26 February 2012 (UTC)

Your submission at Articles for creation: Palmyrene alphabet has been accepted[edit]

AFC-Logo.svg
Palmyrene alphabet, which you submitted to Articles for creation, has been created.
The article has been assessed as Start-Class, which is recorded on the article's talk page. You may like to take a look at the grading scheme to see how you can improve the article.

You are more than welcome to continue making quality contributions to Wikipedia. Note that because you are a logged-in user, you can create articles yourself, and don't have to post a request. However, you may continue submitting work to Articles for Creation if you prefer.

Thank you for helping improve Wikipedia!

MatthewVanitas (talk) 01:54, 12 July 2014 (UTC)

Common script & Unicode[edit]

About your edit in Arabic (Unicode block) [1]. I thinkt this is not the way to do it.

A character in Unicode, can be used in multiple scripts. So in Unicode, that single character gets the script id: 'common'. All fine But a set of characters like 'arabic script' is looking the other direction: for a script it does not matter if a character is used elsewhere. All chars in the arabic script are arabic chars.

The same for inherited characters: they belong to the arabic script, full stop. There is no need to note that they may be used elsewhere.

So the infobox should say: all Arabic characters. -DePiep (talk) 20:28, 27 August 2014 (UTC)

@DePiep: I'd agree with your usage of 'script' if this was an infobox on the Arabic script or language page but this is an infobox specifically for a Unicode block. The script value(s) are taken directly from the Unicode Standard and are also reflected on the Unicode block page. Script has a very specific meaning in the Unicode Standard. The Unicode block infobox has a parameter for 'Major alphabets' which I think is being muddled here with the script parameter. Apart from 'Major alphabets' and 'Note' fields all the information in the Unicode block infobox comes from the Standard itself. I don't want to be the arbiter of the script value for each block... I think it should come from the Standard. I can already envision the arguments over Assamese vs Bengali if we can't point to a definitive source for the script value. If we go down to the character level there's bound to be an argument over whether U+067E ARABIC LETTER PEH is Arabic or Persian as Wikipedia describes it as Pe (Persian letter). DRMcCreedy (talk) 00:26, 28 August 2014 (UTC)
I don't want to be the arbiter - you are right, we cannot have OR. And indeed, some characters in this block have 'common' or 'inherited' for script. Still, I think the Standard has more information that just the script code (which gives one script per character). For example, the name can contain the script name: U+06DA ۚ arabic small high jeem has script code 'inherited' (being a diacritic), but we can conclude that it belongs to the Arabic script (conclude from name and inherit properties). For 'common' script we again can look to at the name, and check other scripts; (e.g., the numbers). Note that 'Persian' script is not defined in Unicode. Still, if we research the whole block, there still can be characters we can not attribute to 'Arabic', so the problem might not be solvable. Btw, your U+067E example is a bad Wiki naming, in Unicode it is defined Arabic. -DePiep (talk) 12:11, 30 August 2014 (UTC)
Are you then OK with me synching the Standard's script names with the Unicode block articles? I would always note Common and Inherited after any specific script names. DRMcCreedy (talk) 18:00, 30 August 2014 (UTC)
Yes, go ahead. That would be factually correct by the source. I was just freewheeling on how to make it more precise. But my algorithm here is not finished. (By the way, do you know this site? It nicely adds "Persian, Urdu, ..." for U+067E). -DePiep (talk) 18:39, 30 August 2014 (UTC)

Chart titles & refs[edit]

In Template:Unicode chart Miscellaneous Symbols, I've been pushing and pulling the title a bit. Added v-t-e box, move ref links to bottom. But I'm not completely happy with the visual outcome. Any ideas from you? -DePiep (talk) 11:28, 30 August 2014 (UTC)

@DePiep: I've had a look and here are my suggestions:
  1. I like the V-T-E but think the title is much too large and competes with the section headings. I tried out a few sizes at User:Drmccreedy/sandbox4 purposefully using "Unified Canadian Aboriginal Syllabics Extended" because it's currently the longest block name. "small" is my favorite font size. "smaller" could work but I still think it distracts from the headings and text.
  2. I like moving the official chart link to the footnotes. I think using "Unicode code chart" for the link is too vague because it appears inside a Unicode code chart. I'd leave the wording "Official Unicode Consortium code chart". I seem to remember a heated discussion over "official" and think this wording was the compromise. In any case I think we should always make it footnote #2 because we'll always have #1 for version and #2 for the official chart.
  3. Ref names containing spaces, like {{ref label|Chart U2600|2}}|...}}, do not work. Clicking on the [x] number no longer takes you to the reference.
  4. Lastly, For the title wording you have "Unicode chart BlockName" instead of simply BlockName. While it works, I think it's redundant to have "Unicode" to the title because the template's likely to be in a section that already mentions Unicode and the word will appear at least twice in references/notes at the bottom of each table. I tried a few different wordings at User:Drmccreedy/sandbox4 for the title. "Chart for BlockName block" is my favorite (even though you could say "block" is also redundant) followed by "Chart for BlockName" but in reality any would work. It's that balance between explicit and concise. I'm also keeping in mind Unicode chart templates with the subset feature like Halfwidth and Fullwidth Forms at Katakana#Unicode. It would be nice if any new title syntax easily allows the subset to be noted, like "Chart for foobar subset of the BlockName block" (for example, "Chart for katakana subset of the Halfwidth and Fullwidth Forms block") or "Chart for foobar subset of BlockName" ("Chart for katakana subset of Halfwidth and Fullwidth Forms"). DRMcCreedy (talk)
Time to ping BabelStone. -DePiep (talk) 20:39, 30 August 2014 (UTC)
First: I've added some links & sandboxes, for us to play. I'll do my demo's in the Math one (guess what's yours).
re 1.a. Yes, the small font is best. End of problem.
re 1b. But it is a simple table title, so it should be bold. (This looks bad now, because the table is made "font big" for the characters, but it spoils the title. See Miscellaneous Symbols/sandbox below for my proposed changes). My solution is: the characters can be big, but the table top should be regular.
re 2. Yes, that chart link should be in the footnote. OK then, it's just a link.
But no, no need to call it "official". (I was the one who heated up the discussion about this; I still claim that "official" wrt Unicode is weasel wording. Unicode does not have anything not official.
I suggest we use {{cite web}} for this. Like, quicky: "Unified Canadian Aboriginal Syllabics (Unicode chart)" (PDF). Unicode Consortium. 16 June 2014. Retrieved 2014-08-30. .
re 3. OK.
re 4. Title wording. Yes, this is not straightforward. I'd say, the table shold be self-contingent (not relying on text surrounding). So somehow it should mention 'Unicode'. Maybe "Miscellaneous Symbols (Unicode chart)"?
re 5 (new) I've started {{Unicode chart/header}}, to be used for all 200+ charts. Once we know what to do in this, it will be useful. -DePiep (talk) 20:58, 30 August 2014 (UTC)
See Template:Unicode chart Miscellaneous Symbols/sandbox [2] (being bold, but only a bit). -DePiep (talk) 21:08, 30 August 2014 (UTC)
It's getting there... @DePiep:@BabelStone:
  • We'll need the first codepoint parameter for both the header and the footer in order to create unique ref labels. It's currently called "block id" in the header template but I'd suggest using something like first or start in part because I don't trust spaces in parameter names. For that reason I'd go with name instead of "block name", grey instead of "has grey" and extranotes or notes instead of "extra notes".
Don't get distracted. See my reply below (all in good faith). -DePiep (talk) 22:39, 30 August 2014 (UTC)
  • I don't think we need a version parameter on the header, just the footer. Shouldn't have to change it in two places each time Unicode releases a new version.
Distraction
  • I see the dates for the cite of the Unicode chart being problematic. It's another thing we'll have to change for each release. Same with retrieved date. We might have the template add it based on version number.
Distraction
  • We'll only need to repeat the block name for the footer if we use it for the cite. Generic wording would avoid this parameter.
Distraction
  • I'm assuming "extra note" would just add the passed text as-is after the two standard references, right?
Distraction
  • Is there a way to have the reference numbers automatically generated within the chart instead of hardcoding them as we do today?
I don't know, will take a look.
  • Visually I don't like "(Unicode chart)" in a different font size. I think it would look better if the title was in a consistent font size. DRMcCreedy (talk) 22:19, 30 August 2014 (UTC)
We disgree. I like the block name being in bold (after all, it's the table title), and have the Unicode mentioned. It's my text proposal for the title.
────────────────────────────────────────────────────────────────────────────────────────────────────Distractions: I started the templates {{Unicode chart/header}} and {{Unicode chart/footer}}, but of course they only will reproduce what we agree (wish I had not mentioned them). Template technicalities are a distraction. Please let us focus on the visual outcome, on what we show in mainspace. E.g., I'd like to see your suggestions in here. It's free. -DePiep (talk) 22:39, 30 August 2014 (UTC)
Move the whole talk to Template talk:Unicode chart? -DePiep (talk)
@DePiep: I've updated Template:Unicode chart Unified Canadian Aboriginal Syllabics Extended/sandbox with a mock up as requested.
The title is bold and identifies it as a Unicode block
I removed the ref numbers. We'll always have at least two notes and all the notes have ref numbers just on the title so the numbers seem superfluous and distracting.
I agree this discussion should move to the template talk page for a wider audience.
And I get distracted easily... DRMcCreedy (talk) 06:37, 31 August 2014 (UTC)
Yes, looks good. I changed the cellspacing from 5px to 2px (as a suggestion); but width settings are still active. Do you think the character should be larger (say 150%)? And should we reduce whitespace (cell padding & widths)? -DePiep (talk) 09:52, 31 August 2014 (UTC)
  • @DePiep: I'm not sure if it's just my computer but I don't really see a difference between 5px and 2px. In fact, removing border="1" cellspacing="0" cellpadding="5" and just relying on class="wikitable" seems about the same to me. If it does to you as well maybe we can just leave it up to wikitable.
  • The character size is currently set to "large". Looking at the manual of style using a percentage, like 150%, might be a better way to go. For me 150% and large are quite similar, at least for this block. No doubt thanks to varying fonts for different blocks some look quite large, like Phags-pa and some quite small, like Mongolian. 150% seems fine.
  • I think the width is important to keep for visually consistent columns. It doesn't make much of a difference for this block but I remember that some looked terrible without it. DRMcCreedy (talk) 23:42, 31 August 2014 (UTC)
Yes, let's see what happens when we leave it to basic class="wikitable" (It's not about your browser). Note that there is also this width setting, per column in the hex-numbers row (2nd row): style="width:20pt". So these set column width (too; it is co-affecting). In Template:Unicode chart Miscellaneous Symbols/sandbox I've removed them, to see the effect.
  • So, as for whitespace we are still playing around. I don't know what looks best, but we should know the control options (there are more than those mentioned). I prefer the number ("150%") above the "large" wording option to have more control, see below.
  • About font size. When set in the table top row, the font-size:150%;, this applies to the whole table. But this should only be for the characters, not for headers &tc (we already concluded). So setting to regular size is done by style="font-size:67%" (150% &times 67% = 100%). For now, I think we should use this to set the sizes for regular text (not the Unicode characters it is about).
  • Not applied: adding a row-header sign (! instead of | pipe). Will bolden the cell text. All these are applied now in the Misc Symb sandbox mentioned .
  • About equal column width. (later more) -DePiep (talk) 09:22, 1 September 2014 (UTC)
  • {{Unicode chart Phags-pa}} uses {{Phagspa}} to format the individual characters & cell. I propose to leave this out of the topic. When we have found a good general setup, we can see into that exception. Similar Template:Unicode chart Mongolian using {{MongolUnicode}}: forget for now. -DePiep (talk) 09:46, 1 September 2014 (UTC)
  • In a separate research, I am looking to get these replacement characters show more nicely: NBSP. Should not influence this topic here (must flow nicely in the chart tables). -DePiep (talk) 09:59, 1 September 2014 (UTC)
────────────────────────────────────────────────────────────────────────────────────────────────────@DePiep:That all sounds reasonable. When you look at equal column width later... I set up a test page without widths at User:Drmccreedy/sandbox4 to compare against Cyrillic script in Unicode#Blocks. DRMcCreedy (talk) 17:48, 1 September 2014 (UTC)

(arbitrary break)[edit]

Yes. Do you know of any chart table that has irregular column widths, today?
If I am correct, we are looking for the right amount of whitespace:character_size at the moment. It takes some patience, but I promise we can control the lot. I also note that page-layout designers love whitespace (at wikimedia , and enwiki pagelayout setting etc), so maybe our outcome will look like ... the current live view.
Just to show, I've added a center-table setting in your sandbox4 '-). Later more. -DePiep (talk) 18:28, 1 September 2014 (UTC)
@DePiep:I think the worst are Template:Unicode_chart_Javanese for irregular size and Template:Unicode_chart_Cyrillic Extended-A for smallness. DRMcCreedy (talk) 22:22, 1 September 2014 (UTC)

Sync script with Unicode Standard[edit]

If we are going to list all scripts associated with a given Unicode block (which I think is a good idea), then maybe we should parenthetically indicate how many characters in the block belong to each script, otherwise the list of scripts may be misleading to the reader. e.g. for Tibetan: "Tibetan (207 characters), Common (4 characters)". What do you think? BabelStone (talk) 10:12, 14 September 2014 (UTC)

@BabelStone:Great idea. I should be able to do that tomorrow. DRMcCreedy (talk) 16:31, 14 September 2014 (UTC)
Great. I'm going to be too busy over the next three weeks to be able to spend much time with this or any of my other suggestions, but I'm always available to help out if needed. BabelStone (talk) 19:15, 14 September 2014 (UTC)

Chart view vs List view for Unicode blocks[edit]

The Unicode block code chart templates give a good visual overview of the block (if the font stuff works!), but is unsatisfactory in many other ways. I have been thinking that in addition to the visual chart view it would be useful to have a list view of assigned characters in each block that provides all the hidden details about the characters. Maybe we should have a button on the Unicode code chart templates that expands the code chart view into a list view (list view hidden by default), with the code point, character name, script, general category, etc. for each assigned character in the block listed in a table. You wouldn't want it for the CJK unified ideographs and Hangul symbols blocks, but I think it would be very useful for other blocks. BabelStone (talk) 10:18, 14 September 2014 (UTC)

This should be useful. Here are the first things that come to mind:
  • Can it include derived age and annotations (from NamesList.txt file)? I'd hope for a separate column for derived age but annotations and other notes could be included with the character name on a new line.
  • Derived age is definitely useful. I'm not sure if there is enough room for annotations, and if you add annotations and notes from NamesList.txt then random editors are going to start editing these notes and adding their own. There is also copyright issue for the notes which I think would preclude us including them. BabelStone (talk) 19:12, 14 September 2014 (UTC)\
  • Sortable columns would be nice.
  • Should this be a different template to accommodate differing widths? Put another way, I think this data would be wider than the current charts.
  • Yes, the current charts would be too narrow. BabelStone (talk) 19:12, 14 September 2014 (UTC)
  • Should we remove the pop-up information for each character once this is in place? Or would we leave that duplicate information (codepoint, name, alias)?
  • I think yes. The pop-up names are far less useful now than they used to be because a few editors have been keenly (over-keenly in my opinion) adding wikilinks to as many characters as possible, and unless you carefully position your cursor in just the right position the Wikilink target name appears instead of the popup names. BabelStone (talk) 19:12, 14 September 2014 (UTC)
  • Agreed. I don't want to duplicate data and the pop-ups are definitely becoming less useful with the linking of individual characters. DRMcCreedy (talk) 19:51, 14 September 2014 (UTC)
  • Would that size of the data be an issue for larger blocks?
  • Possibly. I would leave out CJK Unified ideographs and Hangul syllables (and any future blocks with algorithmic names such as Tangut and Nushu), which would mean the largest block would be Yi syllables with 1,165 characters which may or may not be too long. For CJK unified ideographs etc. we could just have two rows for first and last character in the block. BabelStone (talk) 19:12, 14 September 2014 (UTC)
  • Are we just creating a user-friendly interface to the Unicode Standard data files? DRMcCreedy (talk) 16:31, 14 September 2014 (UTC)
  • I hope not. I think we should restrict ourselves to the most useful properties, and avoid mission creep by adding more and more properties just for the sake of being complete. I would say that character name, formal aliases, general category, script, and derived age are very useful; but combining class category, bidi class, decomposition type/mapping, numeric type/value, case mapping, etc. are not essential and should not be included. I would also avoid repeating the actual character shown in the chart template. BabelStone (talk) 19:12, 14 September 2014 (UTC)

Wikidata for Unicode data[edit]

I think it is wrong, or at least inefficient, for us to be maintaining so much Unicode data for scripts, blocks and characters by hand on en:wp. Such data is needed by all the big wikipedias, but at present it needs to be duplicated for each language version of an article or template. It seems to me that it would be best to maintain Unicode data on Wikidata so that it available to all Wikimedia projects independent of language. Perhaps this would mean Wikidata entries for each Unicode script, each ISO 15924 code, each Unicode block, and each and every assigned Unicode character. I've never used Wikidata so don't know how we would go about doing this, but it is something I think we should try to consider. BabelStone (talk) 10:31, 14 September 2014 (UTC)

I agree, especially if we expand the amount of data for "list view". I'm not familiar with Wikidata either but it would be good to look into it further. DRMcCreedy (talk) 16:31, 14 September 2014 (UTC)
Yes, might be worth trying to involve someone who is involved with Wikidata. I don't think it's urgent, and I have very limited time for Wikipedia at present, but perhaps we can do something about it over the next year. BabelStone (talk) 19:19, 14 September 2014 (UTC)
Actually this is not what Wikidata does. It does not store central data, but only connects same topics across wikis. Simply, it replaced interwiki links. e.g., Moskow (this enwiki) de:Moskau and ru:Москва now all link to wikidata:Q649, the non-language coded id for this object (the city).
Store the data centralised (a sound idea) could be through commons? or wikibooks? (did not research this yet). -DePiep (talk) 11:05, 16 September 2014 (UTC)
Actually, I believe you are wrong. Interwikilinks is just one aspect of Wikidata, but going forward it is intended to act as a central repository of data for Wikimedia projects (Wikidata Introduction). BabelStone (talk) 19:11, 16 September 2014 (UTC)
You are right. Language-free data, so fit for core Unicode. However, that is long term. Last time I tried it was not even possible to simply retrieve exisiting data from wd (to use in enwiki).
At the moment we have Template:Planes (Unicode), that links code ranges to wikibooks. It's an old template here, but I've never bothered to updated those links myself. -DePiep (talk) 19:32, 16 September 2014 (UTC)

Abbr?[edit]

I see you write "char." for "character" in the Unicode template. Nothing wrong with that, but I ask you to consider: write full "character" when possible. It makes much more pleasant reading. Of course, in a table or for informed correspondence we could use the abbrev., but for the wiki Reader-is-King it takes an unneeded mental step. -DePiep (talk) 19:17, 20 September 2014 (UTC)

I've updated Template:Unicode_blocks to use the full word. I've left the abbreviation in the infoboxes (for example, Basic Latin (Unicode block)) where space is at a premium. DRMcCreedy (talk) 19:40, 20 September 2014 (UTC)
Sounds good. (I did not even check). -DePiep (talk) 20:11, 20 September 2014 (UTC)

Templates for Unicode blocks with no code charts[edit]

Hi, you may wish to contribute to the discussion of templates for Unicode blocks with no code charts here. BabelStone (talk) 18:20, 11 October 2014 (UTC)

Updating Unicode version for Unicode chart templates[edit]

Hi, I noticed that when Unicode 7.0 was released you updated all the 200+ Unicode block templates that had not been affected by the Unicode 7.0 release to indicate "As of Unicode version 7.0" -- which is a good thing, but seems really time-consuming. I wonder, would it be a good idea to replace "As of Unicode version 7.0" in all the Unicode block templates with "As of Unicode version {{UnicodeVersion}}" where "UnicodeVersion" is a template containing the current version string (e.g. "8.0" at present), and then when a new version of Unicode is released, all we need to do is update the "UnicodeVersion" template after all the affected Unicode block templates have been updated. What do you think? Pinging DePiep who is the expert at Unicode templates. BabelStone (talk) 12:44, 20 June 2015 (UTC)

I like your idea. I'd want the documentation to include the description you give here and an admonition to not change it until all the templates are updated/verified after a release. DRMcCreedy (talk) 15:09, 20 June 2015 (UTC)
Yes, that was what concerned me, but if anybody does prematurely change the template it would be easy enough to change it back. I'll wait a day or two before doing it in case anyone else has any comments. BabelStone (talk) 17:16, 20 June 2015 (UTC)
Sure have I thought about his often. But. We can not have a "current version number template" (like {{UnicodeVersion}}) that would update each and every page automatically, unchecked. So I say: no. -DePiep (talk) 00:06, 21 June 2015 (UTC)
Oh well, then I guess we'll just have to update all the templates manually. BabelStone (talk) 20:10, 21 June 2015 (UTC)
(edit conflict)Let me rephrase for clarity. If that simple template would exist it could be applied to all Unicode templates and tables etc. after sound checking (manual editing). That is great. Now when a new Unicode version is published, we'd change that version number in the tempalkte once and voila, we are stating that all those tables are "as of Unicode version (latest)". That is a tough statement to make.(What we really need is an option to visit & edit just those pages that are affected by a new version). -DePiep (talk) 20:28, 21 June 2015 (UTC)
re BabelStone 20:10: note that today a sourcing statement "as of version 7.0" is correct! iow, only articles with topics that have changed, like in block additions, are outdated (and still not wrong). -DePiep (talk) 20:28, 21 June 2015 (UTC)
I agree "as of version 7.0" is technically correct for blocks that have not been updated for 8.0, but it can be confusing for readers because they may think that the table is out of date if they know that the current version of Unicode is 8.0. I therefore think that it is preferable to specify "as of" the latest version of Unicode for all blocks, even if they have not been updated since version 1.0. BabelStone (talk) 07:53, 22 June 2015 (UTC)
Agree. It is just to easy any panic about incorrectness. -DePiep (talk) 08:05, 22 June 2015 (UTC)
  • Since Unicode is web-published, I was thinking along this other line. We could make a template {{Cite Unicode}} with optional parameters version=, chapter=, script=, plane=, TR=. Of course it links nicely and automatically to a site page. Not just chart pages, but also chapters and appendices. The version number does not alter with a new release. However, any time we can check all articles using this template. Maybe in maintenance categories even ("Cat:Articles with Unicode version 1 cites)"). When for example Unicode 11 changes chapter 5 (number & content), we can do that maintenance check and update the Cite reference. Note that before someone would do that, the old cite is not wrong (because from the old version, chapter is cite correct. But alas, this takes some development time & thinking. -DePiep (talk) 20:24, 21 June 2015 (UTC)
  • One more idea. BabelStone. Why not create {{Unicode v8.0}} that has text "like "As of version 8.0". You can add that today to where you need it (i.e. add template not change versdion text). Then next year you can more easily revisit those pages (via What-links-here) for a v9 check/update. No harm in sight. -DePiep (talk) 08:46, 22 June 2015 (UTC)
DePiep, thanks for the alternative suggestions. I'll think about them, but for the present I think it is simplest just to manually update the pages. BabelStone (talk) 21:50, 25 June 2015 (UTC)
Yes. -DePiep (talk) 21:55, 25 June 2015 (UTC)