Property talk:P1480

From Wikidata
Jump to: navigation, search


sourcing circumstances
qualification of the truth or accuracy of a source: circa (Q5727902), near (Q21818619), presumably (Q18122778), etc.
Description sourcing circumstances
Data type Item
Template parameter primary dates and places in infoboxes
Domain qualifiers can be used for references and also for claims, if all specified references for claim would have the same qualifier (note: this should be moved to the property statements)
Allowed values
According to this template:

limited set of values, precisely documented on property talk page, including:

According to statements in the property:
circa (Q5727902), presumably (Q18122778), possibly approximate value (Q21097017), unspecified calendar (Q18195782), unspecified calendar, assumed gregorian (Q26877139), unspecified calendar, assumed julian (Q26877143), specified date of both Julian and Gregorian calendar (Q27055388), misprint (Q21096955), miscalculation (Q21096985), misassociation (Q21097088), near (Q21818619), specified date of julian calendar (Q38173183), possible (Q30230067), hierarchical link is not direct (Q50095342), specified date of gregorian calendar (Q51367591) and allegedly (Q32188232)
When possible, data should only be stored as statements
According to this template:


According to statements in the property:
gas lighting (Q856548)circa (Q5727902)
When possible, data should only be stored as statements
Source sources themselves, sometimes infoboxes for import ("born about 1234 year") (note: this information should be moved to a property statement; use property source website for the property (P1896))
Robot and gadget jobs some conditions shall be checked using bot:
See also stated as (P1932), refine date (P4241), earliest date (P1319), latest date (P1326), nature of statement (P5102)
Proposal discussion Property proposal/Archive/25#P1480
Current uses 35,825
[create] Create a translatable help page (preferably in English) for this property to be included here
One of circa (Q5727902), presumably (Q18122778), possibly approximate value (Q21097017), unspecified calendar (Q18195782), unspecified calendar, assumed gregorian (Q26877139), unspecified calendar, assumed julian (Q26877143), specified date of both Julian and Gregorian calendar (Q27055388), misprint (Q21096955), miscalculation (Q21096985), misassociation (Q21097088), near (Q21818619), specified date of julian calendar (Q38173183), possible (Q30230067), hierarchical link is not direct (Q50095342), specified date of gregorian calendar (Q51367591), allegedly (Q32188232): value must be one of the specified items. Please expand list if needed. (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P1480#One of, values statistics, SPARQL
Scope is as qualifiers (Q46466783): the property must be used by specified way only
List of this constraint violations: Database reports/Constraint violations/P1480#Scope, hourly updated report
Pictogram voting comment.svg No source
Statements with sourcing circumstances without reference
Violations query: SELECT DISTINCT ?item { ?st pq:P1480 [] . MINUS { ?st prov:wasDerivedFrom [] } . ?item ?p ?st } LIMIT 2500
List of this constraint violations: Database reports/Complex constraint violations/P1480#No source
This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

New value[edit]

After discussion here: , I created a new item here: disputed (Q18912752) . Can I add this new item to the list of possible values?--Mischa004 (talk) 10:27, 27 January 2015 (UTC)

This would also need to be changed:
Template parameter primary dates and places in infoboxes
--Mischa004 (talk) 10:31, 27 January 2015 (UTC)
Just do it. If there is a serious issue with it the discussion will come up someday, when there is a better or nicer solution.--Giftzwerg 88 (talk) 14:39, 11 February 2015 (UTC)

attributed to (P1773) and possible creator (P1779)[edit]

are two explicit properties expressing uncertainity of authorship with little (2*qualifier, 1*"primary" property) or no apparent usage at all yet). Shouldn't those two not better also be expressed by dedicated values for sourcing circumstances (P1480)? -- Gymel (talk) 22:43, 19 April 2015 (UTC)

And there are purported (de: angeblich) and presumed (de: mutmaßlich) authorships which IMHO are neither reflected here nor by P1773/P1779. And those cases of assumed authorship where it's today beyond any dispute that it can't be true but almost nothing about the possible true creator is known, cf. en:Pseudepigrapha#Authorship and pseudepigraphy: levels of authenticity which describes seven levels or de:Pseudepigraphie#Formen von Pseudepigraphie giving a classification based on the assumption of authorship being performed by the real author/third parties x intentionally/inadvertently. -- Gymel (talk) 23:11, 19 April 2015 (UTC)

And date ?[edit]

What about a use of this property and value circa (Q5727902) as qualifier for properties whose type is date : date of birth (P569), date of death (P570) , ... ?

It is shown in examples, but not compatible with constraint : {{Constraint:Source}} --Odejea (talk) 11:48, 6 December 2015 (UTC)

Indeed, it is used as a qualifier too. So that constraint should be removed in my opinion. Mbch331 (talk) 08:29, 14 December 2015 (UTC)
Yes, I agree that the constraint should be removed. Surely this is a necessary and correct use of circa.--Sic19 (talk) 17:05, 14 December 2015 (UTC)
Checked the history. It was added without discussion, so it can be removed without discussion too. Mbch331 (talk) 19:25, 14 December 2015 (UTC)

Ambiguous meaning[edit]

There are two different documented meanings:

  1. when used with "circa", "likely" etc., it's just a qualifier changing the exact meaning of the main value. It should be based on what a source says, but just like any other non-obvious statement. The label "sourcing circumstances" does not seem to make much sense in this case.
  1. when used with values like "miscalculation" or "misprint", that meaning is profoundly different. The qualifier does not report what the source says, but why we think the source is wrong. In this case, it is synonymous with reason for deprecation (P2241)

I would suggest to drop meaning 2) as reason for deprecation (P2241) does that unambiguously, and change the label to something more descriptive, like "value accuracy". --Zolo (talk) 11:35, 24 March 2016 (UTC)

I suppose that a label like "quality of data" would be closer to reality. --FocalPoint (talk) 17:39, 16 July 2016 (UTC)

I agree to that proposal. -Ash Crow (talk) 16:47, 2 October 2016 (UTC)
Thanks, I have changed the label to "quality of data" (waiting for complaints now...). --Zolo (talk) 11:44, 24 December 2016 (UTC)
@Zolo: :-))) I disagree with the changes that have been made, and have returned to the previous labelling. 'Qualify' and 'quality' mean different things and come from different latin roots. Qualifying with "circa", ie. died c. 25 September 1884 indicates uncertainty of exactness, which, is different from the quality of the date (noting that dates cannot have "quality"). So you might be talking about the quality of the source, but the source could be excellent, however, it cannot get around uncertainty. So this needs a rethink. If you are wanting "quality of data", then we are going to need to split out "circa" dates to a different qualifier.  — billinghurst sDrewth 12:54, 25 December 2016 (UTC)
"qualification of data" would work for "circa"  — billinghurst sDrewth 13:01, 25 December 2016 (UTC)
@FocalPoint, Ash Crow:. Addendum. Is this a case of trying to achieve a number of close circumstances with the one property. We are talking about uncertainty of source, versus uncertainty of knowledge, which are different things.  — billinghurst sDrewth 12:58, 25 December 2016 (UTC)

Hi billinghurst. It is clear now. I do not care for title, but the description for the two properties needs to be something like:

  • uncertainty of source (the source is believed to be wrong)
  • uncertainty of knowledge (the source is accepted as correct, but the source indicates an uncertain value)

Please confirm that I understood correctly. --FocalPoint (talk) 13:45, 25 December 2016 (UTC)

Those are the two that I see. Maybe other cases. Now whether they are one or two properties is open for debate. (I could comment more but it is probably "blah blah blah".)  — billinghurst sDrewth 14:08, 25 December 2016 (UTC)
In practice, "uncertainty of knowledge" is what the property is about. Statistics are here: . Since uncertainy of knowledge has no direct connection to sourcing, any label will be at least as good as "sourcing circumstances".
If the truthfullness of what a source states is disputed, you can show that with statement disputed by (P1310). If it is known to be wrong, you can use the deprecated rank + minimum date (property constraint) (P2310).
I have no strong opinion about the label. "qualification of data" is probably better than "quality of data", but I don't think "quality of data" is wrong (poor quality of the data means that the facts are not well known, not that the source makes a bad job relative to what is achievable). --Zolo (talk) 16:10, 25 December 2016 (UTC)
A later thought, the qualifier used should be able to distinguish the type of uncertainty and that may allow one label, and allow the type of qualifier to differentiate.
@Zolo: Why I was against the "quality of data", the example that I gave came from a report of death of a journalist in Sudan who was captured, and it may have been the 25th that he was killed, or the 26th. the executors didn't say. The data of capture is known, and the date of the discovery of the bodies are unknown, and there is a tight range, but not exact knowledge. Quality of data is excellent, there is just uncertainty +/- a day.  — billinghurst sDrewth 06:08, 28 December 2016 (UTC)
@Zolo, Ash Crow, FocalPoint: we need to go back and tidy up this property as discussed, as you will see the discussion today is building on this ambiguity of "uncertainty of source" v. "uncertainty of knowledge". the longer we wait, the harder the cleanup.  — billinghurst sDrewth 11:28, 7 February 2018 (UTC)


Here are the most used values of this property (query) circa (Q5727902) (30037)
hypothetically (Q18603603) (2877)
presumably (Q18122778) (1975)
disputed (Q18912752) (573)
near (Q21818619) (423)
possible (Q30230067) (407)
hypothesis (Q41719) (209)
non official (Q29509080) (63)
often (Q28962312) (44)
fiscal year (Q191891) (37)
uncertainty (Q13649246) (32)
no label (Q35976085) (26)
doubt (Q34302) (21)
end of (Q40719766) (21)
misprint (Q21096955) (15)
de facto (Q712144) (11)
possibly approximate value (Q21097017) (11)
rarely (Q28962310) (10)
error (Q29485) (9)
official (Q29509043) (9)

Challenge use of "presumably" to qualify a year of birth or death[edit]

I do not find the use of "presumably" to qualify a date of birth/death as that helpful, and hard to manage and qualify in infobox usage. It is not a common practice with the use of "circa", the more expected practice (my opinion). I can see that we can use presumed for some dates where it is within a series of events of known dates, however stepping outside the usual use of circa, seems unusual, especially in our guidance.  — billinghurst sDrewth 01:10, 4 February 2017 (UTC)

Propose new qualifying item "believed"[edit]

I have the source s:Reading, John (d.1692) (DNB00) where it states that John Reading (Q6254393) is 'believed" to be buried in a place. The allowed qualifiers do not meet this circumstance. Obviously it would need to be referenced if used.  — billinghurst sDrewth 10:50, 6 May 2017 (UTC)

@Mbch331, Zolo: prior to my editing ... ^^  — billinghurst sDrewth 16:49, 19 May 2017 (UTC)
@billinghurst: Not really against it, but I then the description of presumably (Q18122778) should be improved to make the distinction clearer. --Zolo (talk) 13:14, 23 May 2017 (UTC)

Before and after[edit]

In the particular context of birth and death dates, is it worth allowing "before" and "after" as valid qualifiers? We get quite a lot of these for historic figures - particularly "after", when they disappear from the record entirely. We can use unknown, of course - not sure which way is better. Andrew Gray (talk) 13:04, 18 June 2017 (UTC)

Isn't that the function of floruit (P1317) to state what is known? Sure it means that we have to presume the other, however, too often I have seen BEFORE/AFTER dates become take as actual dates. I also find them somewhat corrupting when they are used based on a person's individual knowledge.  — billinghurst sDrewth 16:52, 18 June 2017 (UTC)

de facto, interim, acting[edit]

no label (P794) is being deprecated and some of its uses with position held (P39) and country (P17) are being transferred to this qualifier. To accept those statements, I have added de facto (Q712144), interim (Q4895105) and acting (Q4676846) to the list of allowed values of this qualifier so we can use the property to represent statements like Raúl Savarese (Q21694119)position held (P39)  Mayor of Buenos Aires (Q21693213) / sourcing circumstances (P1480)interim (Q4895105). Deryck Chan (talk) 21:22, 4 November 2017 (UTC)

  • Please don't. This has just nothing todo with sourcing.
    --- Jura 21:45, 4 November 2017 (UTC)
    • @Jura1: I was following the proposals at this deletion discussion. I presume we got here because the proponents of this as a replacement for no label (P794)  interim (Q4895105) etc did not distinguish between "circumstances accuracy of statement" and "circumstances and accuracy of sourcing". Please propose a better qualifier to accept these qualifiers and I'll port those qualifiers there instead. Deryck Chan (talk) 22:03, 4 November 2017 (UTC)
"Deryck Chan This property is for "qualification of the accuracy of a statement". For example a statement, like time or place, can be approximate circa (Q5727902), assumed based on other facts presumably (Q18122778), disputed by others disputed (Q18912752), etc. but it can not be acting (Q4676846) or interim (Q4895105). I think there should be a property for Raúl Savarese (Q21694119)position held (P39)  Mayor of Buenos Aires (Q21693213) / P????interim (Q4895105), but sourcing circumstances (P1480), is not it. If there is not any than you should propose one but you can not pick a random existing one and use that. --Jarekt (talk) 02:37, 5 November 2017 (UTC)
Concur with Jarekt's and Jura's opinions. The advice at the deletion discussion seems wrong.  — billinghurst sDrewth 10:12, 5 November 2017 (UTC)
I agree. There is a need for his kind of qualifier, but P1480 isn't suitable. Perhaps subject has role (P2868)? Andrew Gray (talk) 10:43, 5 November 2017 (UTC)
subject has role (P2868) would be the next closest match, though we would still be polluting "roles" with "accuracy of statement". Until a better property gets invented, it would probably be best to dump all these qualifiers over there. Deryck Chan (talk) 17:01, 5 November 2017 (UTC)
The other "catch-all" property is significant event (P793); it's not really right, but it's sometimes good enough for this sort of "I have a special case and want to note it" qualifier. Andrew Gray (talk) 18:45, 5 November 2017 (UTC)
One could argue that the position held is "(acting|interim) mayor of Buenos Aires" and that should be a role on its own that is a subclass of "mayor of Buenos Aires" as what does interim mean anyway? They usually fulfil the role, and the interim is around the term, which we can specify, not around the powers.  — billinghurst sDrewth 21:44, 5 November 2017 (UTC)
Just to clarify, I don't think I said or wrote this.
--- Jura 14:42, 18 November 2017 (UTC)
Okay. I've originally made those alias changes in preparation for adjusting the scope of this property to include things like "de facto". Deryck Chan (talk) 17:20, 8 December 2017 (UTC)
  • @Swpb, Pasleim, Jura1, billinghurst, Multichill: Swpb and Pasleim have widened the purpose of this property to cover both "accuracy of the sourcing" (e.g. this person is presumably born in 1876 [but we aren't quite sure]) and "accuracy of the underlying truth" (the sky is usually blue [but occasionally grey]). I personally think that's an appropriate direction to move towards but want to bring up this discussion again before, well, porting items in. Deryck Chan (talk) 21:22, 12 December 2017 (UTC)
Actually, I have rethought that. I think sourcing circumstances (P1480) might be best limited the accuracy or reliability of a statement, not other aspects of its status, since there are other properties that suit those purposes. (I've made a breakdown of all these qualifiers for my own edification, that might shed light on my thinking.) For "de facto"/"de jure", I've been using determination method (P459), which I've widened accordingly. For "interim"/"acting", subject has role (P2868) is workable. Either way though, I think existing properties can be made to fit the purposes; I don't see much value in a new property. Swpb (talk) 21:35, 12 December 2017 (UTC)
  • Pictogram voting comment.svg Comment Even with the changes made to the constraints I still do not see that "interim", "acting", etc. belong under sourcing circumstances. There is nothing relating to sourcing, it relates to the term and the method of the appointment.  — billinghurst sDrewth 06:24, 13 December 2017 (UTC)
  • Pictogram voting comment.svg Comment This again seems unrelated. @Deryck Chan: Maybe you could explain your usecase and we can try to help you find the right properties/qualifiers. What data do you want to add?
    --- Jura 08:16, 13 December 2017 (UTC)
  • We need to find somewhere to take these statements:
    SELECT ?item ?itemLabel ?property ?propertyLabel ?value ?valueLabel ?asObject ?asObjectLabel
        ?prop pq:P1480 ?asObject .
      	hint:Query hint:optimizer "None" .	
    	?item ?p ?prop . 
    	?property wikibase:claim ?p .  
      	?property wikibase:statementProperty ?ps .
        ?prop ?ps ?value .      
        wd:P39 wikibase:claim ?p
    	SERVICE wikibase:label { bd:serviceParam wikibase:language "en"  }    
    LIMIT 1000
    Try it!
    Also @Swpb, Jura1: Where did you port all those statements that used to say (person)award received (P166)  (award) / as"in memoriam"? --Deryck Chan (talk) 09:57, 13 December 2017 (UTC)
@Deryck Chan: The no label (P794)=in memoriam (Q3509975) qualifiers were changed to determination method (P459)=posthumous (Q1395509) [1]. --Pasleim (talk) 14:25, 13 December 2017 (UTC)
  • Let's solve the initial own first. subject has role (P2868) is fine for de facto, interim, acting. I thought this was resolved as you moved some there already.
    --- Jura 13:12, 13 December 2017 (UTC)
    • Looks like Pasleim moves them to "object has role" while Deryck Chan moves them to "subject has role" or "sourcing circumstances". Can we agree on something first than move them around. In the meantime, please move them back to "as". This was created for cases where people can't identify a better one. Which apparently is the case here. Shuffling them around in an random manner is just bad quality editing.
      --- Jura 15:31, 13 December 2017 (UTC)
Using "object has role" and "subject has role" is not a conflict, it depends on the context which one should be used. I see "sourcing circumstances" to be not wanted according to this discussion. --Pasleim (talk) 15:51, 13 December 2017 (UTC)
Good point. I double checked the statements and in the context (non-P39 statements) it was actually correct. I also found a few other qualifiers being used: statement is subject of (P805), has cause (P828), occupation (P106). position held (P39), determination method (P459), elected in (P2715) ..
--- Jura 16:17, 13 December 2017 (UTC)
(edit conflict) The problem with these properties is that they explicitly qualify either the subject of the object. But what we want to qualify here is the verb (main property). When [person] holds position [position] "as" "interim", neither the person is interim nor the position is interim, but rather the action of holding the position is interim. So subject has role (P2868), object has role (P3831), and applies to part (P518) are all problematic matches because they qualify the subject or the object. sourcing circumstances (P1480) is grammatically closer, but it's strictly about the degree of truth rather than the status of the statement. @Swpb: This mismatch is why I think there should be an "status of statement" / "applies to aspect" qualifier which is separate from all the ones we've used to port out no label (P794) so far. Deryck Chan (talk) 16:29, 13 December 2017 (UTC)
I see the argument that subject has role (P2868) isn't an exact fit, but I'm hesitant to add to the qualifiers without cleaning up the definitions of the existing ones. criterion used (P1013) and determination method (P459) serve closely related purposes, for example. And "applies to aspect" is an alias of applies to part (P518). It should be clear which is the "right" property for any given case, so we don't end up with a mix. Swpb (talk) 21:06, 13 December 2017 (UTC)
I again restate, in the examples given the truthfulness of interim/acting/... is not in argument, so application of P1480 is simply incorrect. Where the "position held" is being described, noting that the position should be specific, the "subject has role" of interim or acting is not describing the person as interim but their qualification of the position. There is ZERO relevance about the sourcing.  — billinghurst sDrewth 23:20, 13 December 2017 (UTC)
If we agree that "sourcing circumstance" is not pertinent, I also think that the discussion here about "the where" they should be moved. It either belongs back at "as", in Project Chat, or at a discussion about your new proposal.  — billinghurst sDrewth 23:24, 13 December 2017 (UTC)

@Deryck Chan: What would you think about calling your new property "condition of statement", and making it a parent of several of the more specific qualifiers? "Condition" is broader than "status" ("status" being a time-dependent condition). "Condition" would be a good fit for interim/acting and de facto/de jure, and probably quite a few other things itself, and it would be a natural parent for sourcing circumstances (P1480), criterion used (P1013), determination method (P459), and maybe others. I think it could capture the generic-ness that Jura1 is looking to retain without being as hopelessly generic as no label (P794). I would happily support such a property. Swpb (talk) 13:53, 14 December 2017 (UTC)

  • One could argue that the three don't necessarily need the same qualifier. "de facto" has nothing to do with "interim" or "acting". The "acting" can be "interim", but not all "interim" are just "acting". The exact meaning might depend on the function and could just have been picked randomly among the options when adding data. There is nothing conditional about someone filling a function as "acting", it's just a special mode of acceding to the function.
    --- Jura 15:30, 14 December 2017 (UTC)
They don't need to use the same qualifier, but I think the fewer qualifiers it takes to cover all cases, the better – and I thought that's where you were coming from too, with wanting to retain P794. I don't agree with your last sentence: I think you may be assuming a different use of the word "condition". I'm not saying that [item][has position][position] is conditional (dependent) on it being an acting position, but just that [acting] is a condition (or mode, or quality) that is true of the statement. Swpb (talk) 15:43, 14 December 2017 (UTC)

Redacted not part of sourcing circumstances (P1480)[edit]

Copied from User talk:Ipoellet: P1480 is about the truthfulness of the value, whereas "redacted" is about a statement in the source in a work, not about the truthfulness of the value. As such you shouldn't be using P1480 to indicate that a reference statement is redacted. P1480 is a qualifier, whereas what you seem to be wishing to do use as part of the reference. I have undone your addition of redacted as a suitable qualifier.  — billinghurst sDrewth 12:56, 6 February 2018 (UTC)

@billinghurst: You are incorrect in your analysis of sourcing circumstances (P1480). While some of the currently allowed values are about the "truthfulness" of a statement, such as misprint (Q21096955) or disputed (Q18912752), others are not. For example, near (Q21818619) speaks to the level of precision in a statement that may nevertheless be fully true and accurate. Another example is that official (Q29509043) and non official (Q29509080) speak to the adoption of a statement by a particular entity, again regardless of whether the fact is true or accurate. In that context, redacted (Q47851538) in fact is more about "truthfulness" than about the other uses to which sourcing circumstances (P1480) is put: a critical reader will question whether textual excisions act to alter the overall message of a redacted work when compared to an unredacted version, which is very much about accuracy and "truthfulness".
You also appear to wish to restrict the application of sourcing circumstances (P1480) to qualify individual statements to the exclusion of qualifying whole works. Yet I am unable to think of a reason why such a restriction is of use to Wikidata. The property appears to have the flexibility to take on both tasks, which are not so very different from each other. Can you provide your reasoning why restricting the property in that way supports the overall project? And if there is such a reason, what property would you recommend using to qualify the accuracy/validity of an entire work? — Ipoellet (talk) 05:08, 7 February 2018 (UTC)
@Ipoellet: "near" is a sourcing circumstance where a person is born near to a township and the like, this is often the fact/citation given in a work; as such it qualifies a cited location. The others that you cite are still qualifiers.

When I think wikt:redact I think of information removed from a document, so I am not seeing how that can qualify a stated fact. Can you provide an example of how you were looking to use it?

Earlier discussions, I believe, determine that we're not to use this property as the marker of the reliability of a reference/citation. So you can cite the data point with a document/reference, and deprecate the factoid per Help:Deprecation. I am not saying that redacted is not a suitable note for a reference, I am saying that I don't see it as a qualifier for this property.  — billinghurst sDrewth 11:19, 7 February 2018 (UTC)

New value: hierarchical link is not direct (Q50095342)[edit]

Property broader concept (P4900) has just been approved, as an informative qualifier on statements giving links to external thesauruses like AAT ID (P1014), Europeana Fashion Vocabulary ID (P3832) etc. P4900 points to the nearest item that has been matched upwards of the present one in the external hierarchy.

This makes possible queries like that returns all items matched to a particular sub-part of the external tree, and for items where the upward relationship cannot (currently) be 'explained' by existing subclass of (P279) relationships.

With such relationships, and for queries like the latter, it is useful to be able to indicate if the item pointed to by broader concept (P4900) corresponds to the direct parent of the present item in the external hierarchy; or if the nearest upward item we can match is not the direct one, but one from further up the hierarchy.

In proof-of-concept tests before the new qualifier was approved, I used part of (P361) for the upward relationship, and indicated when this was different to the direct relation recorded in the source with sourcing circumstances (P1480) = hierarchical link is not direct (Q50095342)

This gave statements like eg Q193204#P1014 if the relationship was direct, and Q763457#P1014 if the next upward item matched does not correspond to the immediate parent entry in the thesaurus, but instead a higher-up entry.

Now that the new property has been created, I should like to go through and replace these trial uses of part of (P361) with the now approved broader concept (P4900). But before doing so, I thought I should confirm here whether sourcing circumstances (P1480) = hierarchical link is not direct (Q50095342) is considered acceptable for use, going forward. Jheald (talk) 17:47, 1 March 2018 (UTC)

Translations are most likely wrong[edit]

See RFC, there are too many translations where either can have benefit to be stored as separated properties, or should just be altered. --Liuxinyu970226 (talk) 02:01, 26 March 2018 (UTC)