This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 20 | ← | Archive 24 | Archive 25 | Archive 26 | Archive 27 | Archive 28 | → | Archive 30 |
The discussion "Hndis needs its own Manual" continues from Archive 25.
continued from Archive 25
:On a page called Title, generally do not create an entry for:
|
Steps I'd like to take:
If any of these prove contentious, the others should still be doable. Comments? -- JHunterJ 19:45, 28 August 2006 (UTC)
(Section temporarily residing on
Wikipedia talk:Manual of Style; when discussion there subsides,
Jerzy•
t will label that copy "closed" and request that any further discussion ensue on a copy to reside on
Talk:List of people by name or its subpages.)
_ _ Making a user rely on
LoPbN, to the exclusion of a page where lks to bios on people bearing the surname, is bad for several reasons.
_ _ Some lks from Dabs into LoPbN do exist; one from
Stein to
List of people by name: St#People named Stein may the first i became aware of. It
was created in October 2003, and i
corrected it following the entries' relocation from
St to
Ste, as i have on occasion done in those three years for some other LoPbN page that got subdivided. No correction has been made, however, for the relocation to the entries' current page,
Stea-Steo. (I haven't, IMO shouldn't, and won't make doing such changes an ongoing priority.)
_ _ It is currently dauntingly labor intensive for an interested editor to detect which pages, among a group of surname-focused pages they are interested in, come to need such a change.
_ _ These objections are irrelevant, however, to markup-sharing schemes that become feasible if one (or better yet two) fairly confined server extensions should become available. (Likewise in the case of more complicated facilities, such as Wiki-style data-bases, that i won't presume to describe.) I call these two extensions as "transextraction" and "symbol setting" (without any claim that these terms are good ones); i describe their application to this problem in the second following subsection at this level,
Transextraction & LoPbN.
Proposals for writing information in one place and having multiple pages share this information, each in a context appropriate to the context of a page better suited than to the one page's purpose than to anothers could in theory be more efficient of editor's time and be more consistent. As i believe i demonstrate in the next section at this level,
"Transclusion into LoPbN?", our present transclusion facility is inadequate to the task, but one (or better yet two) fairly confined server extensions should make it feasible to meet those goals; i describe them their application to this problem in the second following subsection at this level,
Trans-extraction & LoPbN.
--
Jerzy•
t 05:44, 30 August 2006 (UTC)
(Section temporarily residing on
Wikipedia talk:Manual of Style; when discussion there subsides,
Jerzy•
t will label that copy "closed" and request that any further discussion ensue on a copy to reside on
Talk:List of people by name or its subpages.)
There are two current major barriers to using transclusion to avoid duplication of labor in creating groups of name entries for LoPbN and Dabs.
These objections would apply much less, however, if one (or better yet two) fairly confined server extensions should become available. (Likewise in the case of more complicated facilities, such as Wiki-style data-bases, that i won't presume to describe.) I call these two extensions as "transextraction" and "symbol setting" (without any claim that these terms are good ones); i describe their application to this problem in the next subsection at this level,
Trans-extraction & LoPbN.
--
Jerzy•
t 05:44, 30 August 2006 (UTC)
(Section temporarily residing on
Wikipedia talk:Manual of Style; when discussion there subsides,
Jerzy•
t will label that copy "closed" and request that any further discussion ensue on a copy to reside on
Talk:List of people by name or its subpages.)
_ _ CM's comment (my response to which includes a lk to this subsection) is, IIRC, the third time i have heard a proposal for transclusion into LoPbN of stretches of Dab-style name entries (presumably from a handful to hundreds in length); i recall discussing or demonstrating some kind of awkward alternative to the unworkable obvious template approach (to little or no response and effect).
This mention of the general concept is the first i've seen since the introduction of the {{
Persondata}} syntax. That tag, IMO, points the way to doing, in effect, what those proposing transclusion of entries onto LoPbN hope for, with the help of at least one fairly limited server feature (but preferably also one further feature, which is at least as limited).
_ _ This subsection is limited to a technical description of the two features and their application to this problem. For insight into the goals (implicit in the transclusion proposals) that require going beyond current features, see the preceding subsections
"Lk from Dabs into LoPbN?" and
"Transclusion into LoPbN?".
_ _ The feature i am calling "transextraction" (for lack of a better naming idea) is fairly well specified by one pertinent example. One possible syntactic expression of the idea is
and the current contents of Ferdinand Magellan's Persondata tag would give that invocation the same effect as
For the sake of demonstration, {{ T}} could contain (instead of its real content) something along the lines of
The effect is that of looking up the values assigned in the {{
Persondata}} tag within that bio, and using them as the parameters of {{tl:T}}. (The parameters anticipated by the current {{
Persondata}} could not actually support templates capable of building entries that meet our standards for these lists; doing that would require either inventing another tag, say {{tl:Personentrydata}}, or adding parameters to the existing one, or restructuring the existing one by breaking up into smaller "chunks" some parameters (which function as "fields" bcz of its data-base role) that it currently has.)
_ _ ({{
Persondata}} exposed the implicit potential in MediaWiki for one small but fundamental DBMS feature, the creation of
tuples; the Persondata tag has the intention of being used as part of the interface for non-MediaWiki DBMSs to extract data from those tuples in bios, if by no other means, by reading the markup in the corresponding pages. (MediaWiki relies on a data-base component that stores and retrieves the current and former versions of pages, and the info seen on page-history pages and Logs; the Persondata-based mini-database, like virtually everything else on WP, depends on it, but should not be confused with it.) Implementing such "transextraction" as i propose here would amount to complementing that with another small but crucial DBMS feature, one for extraction of data from those tuples for reformating via the template system. One argument against permanent provision of "transextraction", and perhaps against using it even temporarily, would be that it is a limited and ad hoc feature that should properly be provided as part of a broader DBMS capability. I am not arguing on either side of those questions, if only bcz i consider this description to be worthwhile whether as
_ _ A second feature, perhaps easier to provide than transextraction, would multiply the effectiveness of transextraction in making editing effort that uses it more efficient. I call it (again for lack of a better name) "symbol setting". It would enable editors to create symbols functioning like the existing {{PAGENAME}} and {{CURRENTDAY}} ones, without any effect outside the respective pages they are created on (other than through their effect on how those pages are rendered, transcluded, substituted, or transextracted elsewhere). The symbol setting probably should take two forms, perhaps
and
The Const version might have to appear before any text, and would set the meaning of a symbol (SYM in these examples) and render ineffective any Var settings, on the same page, of the same symbol. VAR settings, on the other hand could be repeatedly changed, staying effective until the next one that sets the same symbol, or the end of the page. In the LoPbN/transextraction context, the use i contemplate is making the same template render differently depending on LoPbN pages setting the same symbol differently from the way Dab pages would do. The templates in question would each contain a series of transclusions utilizing {{ Persondata}} tags of bios. When preceded by
(on an LoPbN page), the transclusion
would be equivalent to
while preceding it by
(on a Dab) would make it equivalent to
This would accomplish nothing that could not be achieved by copying a symbol-less stretch of "transextractionized" Dab or LoPbN markup, doing a global change on the multiple copies of the template name, and pasting it into a page of the other kind -- except saving that editor effort, and probably reducing occasional clerical errors.
--
Jerzy•
t 05:44, 30 August 2006 (UTC)
See also new discussion at Wikipedia:Administrators' noticeboard/Incidents#Name_pages_and_disambiguation (Archived to Wikipedia:Administrators' noticeboard/IncidentArchive135#Name pages and disambiguation - CarolGray 11:51, 9 January 2007 (UTC)) -- JHunterJ 00:43, 11 September 2006 (UTC)
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 20 | ← | Archive 24 | Archive 25 | Archive 26 | Archive 27 | Archive 28 | → | Archive 30 |
The discussion "Hndis needs its own Manual" continues from Archive 25.
continued from Archive 25
:On a page called Title, generally do not create an entry for:
|
Steps I'd like to take:
If any of these prove contentious, the others should still be doable. Comments? -- JHunterJ 19:45, 28 August 2006 (UTC)
(Section temporarily residing on
Wikipedia talk:Manual of Style; when discussion there subsides,
Jerzy•
t will label that copy "closed" and request that any further discussion ensue on a copy to reside on
Talk:List of people by name or its subpages.)
_ _ Making a user rely on
LoPbN, to the exclusion of a page where lks to bios on people bearing the surname, is bad for several reasons.
_ _ Some lks from Dabs into LoPbN do exist; one from
Stein to
List of people by name: St#People named Stein may the first i became aware of. It
was created in October 2003, and i
corrected it following the entries' relocation from
St to
Ste, as i have on occasion done in those three years for some other LoPbN page that got subdivided. No correction has been made, however, for the relocation to the entries' current page,
Stea-Steo. (I haven't, IMO shouldn't, and won't make doing such changes an ongoing priority.)
_ _ It is currently dauntingly labor intensive for an interested editor to detect which pages, among a group of surname-focused pages they are interested in, come to need such a change.
_ _ These objections are irrelevant, however, to markup-sharing schemes that become feasible if one (or better yet two) fairly confined server extensions should become available. (Likewise in the case of more complicated facilities, such as Wiki-style data-bases, that i won't presume to describe.) I call these two extensions as "transextraction" and "symbol setting" (without any claim that these terms are good ones); i describe their application to this problem in the second following subsection at this level,
Transextraction & LoPbN.
Proposals for writing information in one place and having multiple pages share this information, each in a context appropriate to the context of a page better suited than to the one page's purpose than to anothers could in theory be more efficient of editor's time and be more consistent. As i believe i demonstrate in the next section at this level,
"Transclusion into LoPbN?", our present transclusion facility is inadequate to the task, but one (or better yet two) fairly confined server extensions should make it feasible to meet those goals; i describe them their application to this problem in the second following subsection at this level,
Trans-extraction & LoPbN.
--
Jerzy•
t 05:44, 30 August 2006 (UTC)
(Section temporarily residing on
Wikipedia talk:Manual of Style; when discussion there subsides,
Jerzy•
t will label that copy "closed" and request that any further discussion ensue on a copy to reside on
Talk:List of people by name or its subpages.)
There are two current major barriers to using transclusion to avoid duplication of labor in creating groups of name entries for LoPbN and Dabs.
These objections would apply much less, however, if one (or better yet two) fairly confined server extensions should become available. (Likewise in the case of more complicated facilities, such as Wiki-style data-bases, that i won't presume to describe.) I call these two extensions as "transextraction" and "symbol setting" (without any claim that these terms are good ones); i describe their application to this problem in the next subsection at this level,
Trans-extraction & LoPbN.
--
Jerzy•
t 05:44, 30 August 2006 (UTC)
(Section temporarily residing on
Wikipedia talk:Manual of Style; when discussion there subsides,
Jerzy•
t will label that copy "closed" and request that any further discussion ensue on a copy to reside on
Talk:List of people by name or its subpages.)
_ _ CM's comment (my response to which includes a lk to this subsection) is, IIRC, the third time i have heard a proposal for transclusion into LoPbN of stretches of Dab-style name entries (presumably from a handful to hundreds in length); i recall discussing or demonstrating some kind of awkward alternative to the unworkable obvious template approach (to little or no response and effect).
This mention of the general concept is the first i've seen since the introduction of the {{
Persondata}} syntax. That tag, IMO, points the way to doing, in effect, what those proposing transclusion of entries onto LoPbN hope for, with the help of at least one fairly limited server feature (but preferably also one further feature, which is at least as limited).
_ _ This subsection is limited to a technical description of the two features and their application to this problem. For insight into the goals (implicit in the transclusion proposals) that require going beyond current features, see the preceding subsections
"Lk from Dabs into LoPbN?" and
"Transclusion into LoPbN?".
_ _ The feature i am calling "transextraction" (for lack of a better naming idea) is fairly well specified by one pertinent example. One possible syntactic expression of the idea is
and the current contents of Ferdinand Magellan's Persondata tag would give that invocation the same effect as
For the sake of demonstration, {{ T}} could contain (instead of its real content) something along the lines of
The effect is that of looking up the values assigned in the {{
Persondata}} tag within that bio, and using them as the parameters of {{tl:T}}. (The parameters anticipated by the current {{
Persondata}} could not actually support templates capable of building entries that meet our standards for these lists; doing that would require either inventing another tag, say {{tl:Personentrydata}}, or adding parameters to the existing one, or restructuring the existing one by breaking up into smaller "chunks" some parameters (which function as "fields" bcz of its data-base role) that it currently has.)
_ _ ({{
Persondata}} exposed the implicit potential in MediaWiki for one small but fundamental DBMS feature, the creation of
tuples; the Persondata tag has the intention of being used as part of the interface for non-MediaWiki DBMSs to extract data from those tuples in bios, if by no other means, by reading the markup in the corresponding pages. (MediaWiki relies on a data-base component that stores and retrieves the current and former versions of pages, and the info seen on page-history pages and Logs; the Persondata-based mini-database, like virtually everything else on WP, depends on it, but should not be confused with it.) Implementing such "transextraction" as i propose here would amount to complementing that with another small but crucial DBMS feature, one for extraction of data from those tuples for reformating via the template system. One argument against permanent provision of "transextraction", and perhaps against using it even temporarily, would be that it is a limited and ad hoc feature that should properly be provided as part of a broader DBMS capability. I am not arguing on either side of those questions, if only bcz i consider this description to be worthwhile whether as
_ _ A second feature, perhaps easier to provide than transextraction, would multiply the effectiveness of transextraction in making editing effort that uses it more efficient. I call it (again for lack of a better name) "symbol setting". It would enable editors to create symbols functioning like the existing {{PAGENAME}} and {{CURRENTDAY}} ones, without any effect outside the respective pages they are created on (other than through their effect on how those pages are rendered, transcluded, substituted, or transextracted elsewhere). The symbol setting probably should take two forms, perhaps
and
The Const version might have to appear before any text, and would set the meaning of a symbol (SYM in these examples) and render ineffective any Var settings, on the same page, of the same symbol. VAR settings, on the other hand could be repeatedly changed, staying effective until the next one that sets the same symbol, or the end of the page. In the LoPbN/transextraction context, the use i contemplate is making the same template render differently depending on LoPbN pages setting the same symbol differently from the way Dab pages would do. The templates in question would each contain a series of transclusions utilizing {{ Persondata}} tags of bios. When preceded by
(on an LoPbN page), the transclusion
would be equivalent to
while preceding it by
(on a Dab) would make it equivalent to
This would accomplish nothing that could not be achieved by copying a symbol-less stretch of "transextractionized" Dab or LoPbN markup, doing a global change on the multiple copies of the template name, and pasting it into a page of the other kind -- except saving that editor effort, and probably reducing occasional clerical errors.
--
Jerzy•
t 05:44, 30 August 2006 (UTC)
See also new discussion at Wikipedia:Administrators' noticeboard/Incidents#Name_pages_and_disambiguation (Archived to Wikipedia:Administrators' noticeboard/IncidentArchive135#Name pages and disambiguation - CarolGray 11:51, 9 January 2007 (UTC)) -- JHunterJ 00:43, 11 September 2006 (UTC)