Talk:Unsupported titles/`period``period`

RFV discussion: September 2011–March 2012

The following information has failed Wiktionary's verification process (permalink).

Failure to be verified means that insufficient eligible citations of this usage have been found, and the entry therefore does not meet Wiktionary inclusion criteria at the present time. We have archived here the disputed information, the verification discussion, and any documentation gathered so far, pending further evidence.
Do not re-add this information to the article without also submitting proof that it meets Wiktionary's criteria for inclusion.

---

Unsupported titles/Double period

Rfv-sense: (Internet) punctuation to end a sentence or phrase, similar to ., except that it often connotates an unfinished or incomplete thought, something that someone wants to say but can't, or a gloomy or resigned feeling. -- Liliana • 22:00, 23 September 2011 (UTC)

It is an illiterate version of "...". I suppose it exists. I am not inclined to try to attest it. I can't believe it has the subtle connotations given above. Equinox ◑ 18:58, 25 September 2011 (UTC)

RFV-failed. - -sche (discuss) 07:34, 1 March 2012 (UTC)

2016 deletion discussion

The following information has failed Wiktionary's deletion process.

It should not be re-entered without careful consideration.

---

..

"The concatenation operator in Lua." Not part of a human language; not used in running text, only in source code. Remember how the APL symbol entries were deleted. We don't include keywords like endif either unless they have entered English grammatically. Equinox ◑ 12:54, 21 April 2016 (UTC)

BTW, here is a list of the operators in just one language (Perl): [1]. Equinox ◑ 12:56, 21 April 2016 (UTC)

IMO, we should keep some symbols of programming languages like this. Other examples: = (assignment operator) and == (comparison operator). See also the multiple meanings of $. The full list of existing entries for programming/computing symbols should be at Category:mul:Programming and Category:mul:Computing.

Related discussions created by Equinox recently: User talk:Daniel Carrero#Entries like /* */ and User talk:Octahedron80#Programming operators. In the latter, @Octahedron80 asked: "why the mathematical symbols and emojis can be included here if they are not the human language?" (but, to be fair, emojis do feel like human language to me, as in, they're used in human text :) :p :/) --Daniel Carrero (talk) 13:02, 21 April 2016 (UTC)

• Delete or at least move to an Appendix. It's not a word and not in a language. —Aɴɢʀ (talk) 13:54, 21 April 2016 (UTC)

  Shouldn't the "parent directory" sense also be deleted? --WikiTiki89 21:22, 21 April 2016 (UTC)

Keep because operators are the symbols that have been used for decades like other deciplines' ones (such as mathematics, thermodynamics, engineering, linguistics, medicine, etc) and have been used in many textbooks. You might think that they are not read by human? No, they are actually read by human so we can write the codes meaningfully. (That is we call the high-level programming language.) Machines do not directly read codes; the codes must be compiled to binary values so they will understand in background. You should not just want to delete them because you do not know. In the contrast, there are many symbols out there that are generally not used in human languages (and sometimes we do not understand their specialities) still exist in this project. Additionally, there is also other meaning of .. as a range either, for example 1..5 mean from 1 to 5. I must admit that most of programming languages are from English but symbols are translingual. --Octahedron80 (talk) 01:55, 22 April 2016 (UTC)

• I did not understand the part "You should not just want to delete them because you do not know." Were you assuming something about the nominator's knowledge of programming languages? That aside, I agree with most of what you said. I added the "range operator" sense now in .. per your comment. --Daniel Carrero (talk) 02:13, 22 April 2016 (UTC)
  • I apologise if my message bothered you. My point is that we want to expand reader's knowledge who never know them before. --Octahedron80 (talk) 02:17, 22 April 2016 (UTC)
    • Your message didn't actually bother me, I just found it a little odd at first, but that's OK. Thanks for the clarification. That's a good point, too, IMO. --Daniel Carrero (talk) 02:33, 22 April 2016 (UTC)
• A question to keepers: Shall we include JOptionPane (Java), std::cin (C++), equ (Win Batch), foreach (Perl) as quasi-attested in source code? All keywords and all APIs in computing languages, quasi-attested in source code? Why is the Equinox rationale "not used in running text" not good enough for deletion? --Dan Polansky (talk) 10:46, 23 April 2016 (UTC)
  • The very basic keywords like int, integer, short, long, double, real, bool, boolean, string, begin, end, if, else, elseif, endif, while, do, loop, for, foreach, try, catch, class, object, array, table, function, return, etc. and programming operators (might be symbolic or mnemonic) should be include because they reflect the basic concept of computer science. Note that same keywords and operators are usually used in many languages. (And I know many languages.) Other advanced classes and libraries (JOptionPane & std::cin) should not be included because they are language-specific. The string concatenation is an essential concept or we could not see wanted messages. --Octahedron80 (talk) 02:56, 25 April 2016 (UTC)

    I don't have any strong opinion concerning terms like int, integer, begin, end, etc. Currently, endif is defined as English for "(computing) A directive, in several programming languages, that marks the end of an if statement, especially one containing multiple if .. then .. else statements". I don't particularly like when I see those defined as English entries, but that's just a gut feeling that I don't feel able to translate in rational thinking yet. I wonder if one could make the argument that, if the plural is attestable ("endifs"), then maybe it really counts as an English word, but then again, "There are 5 thes in that sentence." would not make "thes" attestable.

    I just wanted to create entries for some programming symbols because some already existed and they seemed a good idea to understand the syntax of programming languages. If anything, I don't think removing all computing senses from, say, + would turn out to be very helpful. Since there are math, genetics, electricity, chess and whatever other senses in that entry, it would feel incomplete (at least IMHO) if it does not have some computing senses too. (unless someone proposes a wider project of removing many Translingual symbols from various contexts) This discussion feels more about general policies for the inclusion of programming language terms rather than a request for the deletion of a sense of .. specifically so I wonder if there are any computing symbols that everybody would want to see in our entries, like perhaps @ (in e-mails) and logical symbols like &&. --Daniel Carrero (talk) 23:46, 26 April 2016 (UTC)

  Consideration of the form "X should not be included because they are language-specific" is not related in any way to WT:CFI, AFAICT. Furthermore, in relation to that consideration, Perl ".." and Lua ".." are language-specific: multiple widely used programming languages do not have the operator. --Dan Polansky (talk) 06:46, 30 April 2016 (UTC)

• I don't see why one sense is nominated and not the other two. Are any of the three used in human language? Renard Migrant (talk) 16:59, 23 April 2016 (UTC)
• Delete per nom: "Not part of a human language; not used in running text, only in source code." In my words, this does not seem attested in use to convey meaning; "use" in the middle of computer code is not use in English. This could thus go to RFV, but there, a discussion could arise about whether various quotations count as attesting, so let us have it in RFD and handle it here. As for the other two senses, these should be deleted as well; the third one was added after this RFD nomination in diff. --Dan Polansky (talk) 06:42, 30 April 2016 (UTC)
• Delete. --WikiTiki89 14:45, 22 September 2016 (UTC)
• Delete No compelling keep argument. DCDuring TALK 17:46, 22 September 2016 (UTC)
• Keep but remove the Lua sense. —Enosh (talk) 09:32, 23 September 2016 (UTC)
  • Why keep the Perl/Swift sense and remove the Lua sense? Is it because the sense "range operator" occurs in at least two programming languages and the sense "concatenation operator" occurs in just one (Lua)? By this logic, if we find a couple of other programming languages that use ".." as a concatenation operator, I assume the sense could stay, or be restored? Where to draw the line? For example, I support keeping both senses of "..", and keeping a bunch of entries for regex symbols: $, ^, ., etc. --Daniel Carrero (talk) 11:46, 23 September 2016 (UTC)

    The RFD rationale is that it's not part of a human language and not used in running text. Even if every single programming language has a certain operator, that doesn't validate it in Wiktionary. Equinox ◑ 12:02, 23 September 2016 (UTC)

    Should we delete all programming language symbols, including some of the "main" ones such as == and ++? If yes, then that would be a consistent decision to have only human languages as argued. But if not, then the problem with ".." meaning "concatenation operator" is that only 1 language uses it, and the decision might be revised eventually if that specific meaning catches on and becomes a part of many programming languages. --Daniel Carrero (talk) 12:08, 23 September 2016 (UTC)

    Yes, we should delete all programming language symbols. Your examples of == and ++ would be kept because they are used occasionally in human languages, but the programming language senses should be deleted (but can be mentioned in the etymology). --WikiTiki89 13:38, 23 September 2016 (UTC)

    I'm thinking of creating a BP discussion + vote eventually, with the proposal "Deleting and disallowing all programming language symbols." (I would vote oppose) to see if people agree with this rule concerning all entries. Of course, we might simply have a big RFD discussion for all the entries, but it wouldn't be the same as having that explicit rule to prevent future entry creations. WT:CFI says nothing about allowing or disallowing them, but I'm aware that even if such a vote failed, it does not mean that all programming language symbols are accepted by default. --Daniel Carrero (talk) 14:25, 23 September 2016 (UTC)

    Okay, I've changed my mind I weakly support, but I still think we should allow basic keywords like Octahedron mentioned above (seems like they would also be citable in running text). And yes occurring in more than one programming language (and not a very popular one at that) is important IMO. —Enosh (talk) 14:45, 23 September 2016 (UTC)

• Delete. Way too context-specific. It is misleading to have such symbols ascribed any very specific meaning if the meanings differ among computer languages, possibly even in different versions of the same language. Can we tell in what languages and with what meaning the symbol is most used? The computer-language specific senses would seem to me to be excellent candidates for inclusion in an Appendix with a sortable table (or tables).

Why would anyone rely on Wiktionary as a good source of the meaning of such symbols when we are not even a reliable dictionary of English? DCDuring TALK 12:01, 23 September 2016 (UTC)

You voted twice. --Daniel Carrero (talk) 12:09, 23 September 2016 (UTC)

Sense deleted. bd2412 T 19:28, 23 September 2016 (UTC)

RFD discussion: October 2016–June 2017

The following information has failed Wiktionary's deletion process (permalink).

It should not be re-entered without careful consideration.

---

..

Unsupported_titles/Double_period stands for "..", obviously.

• rfd-sense: (computing) The parent directory.
• rfd-sense: (programming) A range operator in some programming languages, including Perl and Swift.

Deletion rationale: Not in use to convey meaning in natural language; not used in running text, only in source code. One example in the entry is this: Type "cd PhotosWallpapers" to go to the Wallpapers folder. Then you can type "cd .." to go to back to the Photos folder.‎ That is not use in natural language. A similar deletion rationale was used in a previous RFD now archived at Talk:Unsupported titles/Double period. --Dan Polansky (talk) 18:08, 8 October 2016 (UTC)

Delete per previous discussion. Equinox ◑ 18:14, 8 October 2016 (UTC)

P.S. Plenty more of these to be found elsewhere, e.g. # is "the ID selector in CSS". Equinox ◑ 18:26, 8 October 2016 (UTC)

Keep and add more programming language symbols. --Daniel Carrero (talk) 19:53, 8 October 2016 (UTC)

Do you think your keep in based on CFI? Do you intend the Translingual in the entry to mean trans-programming language? Shall we include JOptionPane (Java), std::cin (C++), equ (Win Batch), foreach (Perl) as quasi-attested in source code? All keywords and all APIs in computing languages, quasi-attested in source code? --Dan Polansky (talk) 21:38, 8 October 2016 (UTC)

That is a direly needed thing, for the world in general, you must admit. Especially for users of this project who have the questionable pleasure of acquainting Lua... Korn [kʰũːɘ̃n] (talk) 21:42, 8 October 2016 (UTC)

Some people also need to know how to change a tire, but that doesn't make it dictionary material. Chuck Entz (talk) 22:26, 8 October 2016 (UTC)

Yes. Let's add JOptionPane (Java), std::cin (C++), equ (Win Batch), foreach (Perl). Above all, let's add all symbols such as $, &&, ==. --Daniel Carrero (talk) 22:04, 8 October 2016 (UTC)

That is an insane thing to say. Are you saying we should include every class name in the Java standard library? DTLHS (talk) 22:06, 8 October 2016 (UTC)

That's no less than insane (I chose the same word before the edit conflict with DTLHS above). JOptionPane isn't even a keyword but an API/framework class. Extending this to .NET, to take one lone example, we would be creating (undefinable!) entries for many thousands of classes such as XmlSerializer, ToolStripSeparatorRenderEventArgs and AsymmetricSignatureDeformatter. And that's before we get onto the property, method and constant names within each of those thousands of classes — just in .NET, not C++, Java or any of hundreds of other frameworks! Equinox ◑ 22:09, 8 October 2016 (UTC)

There's endless variation between programming languages in exactly what a given token "means", with a lot of it coming from the architectures of the different languages. Even details of the implementation of languages on different operating systems and of different versions/builds on the same system can make significant differences. This is a massive can of worms that should be avoided at all costs. Besides, this looks like a matter of operating systems rather than programming languages. Chuck Entz (talk) 22:26, 8 October 2016 (UTC)

• Delete. DCDuring TALK 03:27, 9 October 2016 (UTC)
• Comments. 1. I suspect use as a range operator is attested in running English on Usenet and the like (derived from Perl or somewhere). If so, the definition can be broadened and the sense kept. 2. This is not only a range operator but also a flip-flop operator, and, if kept for its computing senses, is missing that sense.​—msh210℠ (talk) 20:22, 28 November 2016 (UTC)

Senses deleted. bd2412 T 20:04, 6 June 2017 (UTC)