Wiktionary:Beer parlour/2016/September: difference between revisions

Content deleted Content added

Inline

Revision as of 19:57, 9 September 2016

`{{also}}` template

Hello -- I noticed that of the c. 495 thousand entries which differ from other entries only in diacritic marks or capitalisation, only c. 172 thousand have {{also}} templates. Would it be worthwhile for me to add these to the remainder? Also, some dozens of thousands which do have these templates are missing a subset of the items in their respective congruence classes. Would it also be worthwhile to complete the arguments for these templates? An example is gort and ğort. Apologies for coming here with such a fiddly question. Isomorphyc (talk) 01:56, 1 September 2016 (UTC)[reply]

Yes, if you're confident you can de-diacritize and classify them correctly. DTLHS (talk) 01:59, 1 September 2016 (UTC)[reply]

If it can be done conveniently (and correctly), yes.

Some users, especially but not only, in English-speaking countries are not facile with diacritics, eg, me. More importantly, I don't think anonymous users have access to the means we offer to overcome keyboard limitations.

IMO the most important part of the task is to make sure that on all entries that use only the no-diacritic Roman character set {{also}} includes all the entries that use diacritics that correspond to the plain entries. English, Latin, and "Translingual" are the only languages that matter to me. A smaller subset would be only lemma entries.

I'm sure there are other points of view. DCDuring TALK 02:10, 1 September 2016 (UTC)[reply]

Yes, please! I have asked before for someone to do this. Note that there may be a limit to how many arguments {{also}} can handle, and there is in any case a limit to how many we would want to display (let's discuss what that would be: more than 15 links?). For terms that would otherwise display more than that number of alsos, it is preferable to set up and link to an appendix, the way a links to Appendix:Variations of "a" rather than listing all 100+ variants directly in a. - -sche (discuss) 02:20, 1 September 2016 (UTC)[reply]

@-sche: For what it is worth, there are 77 congruence classes having more than 15 members and 129 classes having more than ten members. The largest groups are bo (19), y (19), s (20), sa (20), n (21), i (24), u (38), e (41), o (57) and a (61). My lists currently do not include differences in punctuation; the classes will be slightly larger and more numerous when this is included. The idea of creating an appendix for classes larger than ten or fifteen sounds reasonable to me, but if I create such appendices, they will provide less information than those which already exist. I would be uncomfortable also including, for example, the same sequence of letters in other scripts or Hanzi represented by the same letters in some transliteration scheme, as is currently the practice. I do believe this can be done without errors on a very large and somewhat easy to define subset of the relevant entries, mostly deferring work on scripts with which I may be uncomfortable. Isomorphyc (talk) 02:47, 1 September 2016 (UTC)[reply]

Since we're talking about the difference between no appendix and one that's not as complete as it possibly could be, I don't see the problem: this is a wiki, and others can expand on those later. Chuck Entz (talk) 03:32, 1 September 2016 (UTC)[reply]

Yes - I think that a bot could do this even better. SemperBlotto (talk) 05:39, 1 September 2016 (UTC)[reply]

It's well suited to a bot, but a bot would not be able to create the appendix pages when there are larger numbers. To do this, the appendix pages would need to follow a standard format and not have any additional information added. —CodeCa t 12:25, 1 September 2016 (UTC)[reply]

But a bot could generate a list of appendix pages that need to be created and pages that need to be added to them. --Wiki Tiki 89 12:54, 1 September 2016 (UTC)[reply]

I'm all in favor of this. If there's any risk of {{also}} taking more than about 8 or 9 arguments, then an "Appendix:Variations of..." should be created anyway. —Aɴɢʀ (talk) 11:26, 1 September 2016 (UTC)[reply]

Second LexiSession : paths, roads and ways

Dear all,

Apologies for writing in non-native English; please fix any mistakes you may encounter in these lines!

The Tremendous Wiktionary User Group, a nice and open gathering of Wiktionarians, is happy to introduce the second chapter of our collective experiment: LexiSession.

So, what is a LexiSession? The idea is to coordinate contributors from different languages to focus on a shared topic, to enhance all projects at the same time! It may remind you of the Commons monthly contests, but here everyone is a winner! First LexiSession was about cat and it was a beginning. For this second LexiSession, we offer a month - until the end of September - to pave the way! There is plenty of names for different kind of roads, streets, avenues, and ways, and wiktionaries can be very helpful to help people to pick the correct one to describe or to translate.

English Wiktionary already have a Wikisaurus:road and a Wikisaurus:way but there is still a lot of information to provide. Well, why is it almost in alphabetical order? How to distinguish between roadway and motorway (for instance)? Is it possible to help readers with pictures or something? These are not instructions, and everyone is welcome to imagine new solutions to provide information about semantic networks and variation. Also, you may be interested to know that French Wiktionary already has eight different thesaurus about streets in eight different languages, including English.

Please share your contributions here! You can also have a look at what other Wiktionarians are doing, on the LexiSession Meta page. We will discuss the processes and results in Meta, so feel free to have a look and suggest topics for the following LexiSession.

Thank you for your attention, and I hope you will be interested in this new way of contributing. I'll get back to you later this month for an update! Noé (talk) 10:53, 1 September 2016 (UTC)[reply]

Great topic (wasn't too keen on the cats). For this session I'm especially interested in local names which are only used in a specific city or region. Also interesting would be to describe (also visually?) hierarchies of paths. – Jberkel (talk) 12:23, 1 September 2016 (UTC)[reply]

@Noé I'll try to contribute more to this one, provided school doesn't get in the way! Let's hope participation is better than last time. :) (And as a tiny note about your English, don't forget that the third person singular of have is has....) Andrew Sheedy (talk) 01:38, 2 September 2016 (UTC)[reply]

@Noé another correction, also there are plenty of names.

borrowing → bor

Wiktionary:Votes/2016-07/borrowing, borrowed, loan, loanword → bor passed. Results: 14-5-3 (73.68%-26.32%) (not counted: +1 late oppose vote). Can someone please do the honors and edit the template in all entries?

FYI: See Thread:User talk:CodeCat/borrowing → bor. In the discussion, I asked CodeCat first, but she said: "I don't think it's right to do it given the strong opposition." Do we need to discuss this further before doing the change? I was hoping we could go on with it and have {{bor}} used in a way more consistent with {{inh}} and {{der}}.

As I mentioned in the conversation with CodeCat, I believe I found some important numbers concerning how the templates are used. Correct me if I make any mistake in the numbers or their interpretation. {{inh}} and {{inherited}} were created together, and it appears that almost all entries that display an etymological inheritance use the shorter form. {{borrowing}} was all we had available for 5 years -- that is, the shorter {{bor}} did not exist. Then {{bor}} was created 1 year ago and about 2/3 of entries of borrowed terms already use {{bor}} rather than {{borrowing}}. This is one reason why I see a trend towards shorter names, confirmed in the vote.

In the discussion, CodeCat suggested leaving shortcuts as shortcuts and long forms as long forms. Feel free to discuss this idea. I disagree with it: people who used the longer syntax {{borrowing|it|pizza|lang=en}} in entries from 2010 to 2015 did it because it was the only format available; once the shorter {{bor|en|it|pizza}} came to exist, people started to use it. --Daniel Carrero (talk) 16:01, 1 September 2016 (UTC)[reply]

Distinction between topical and context-based usage categories?

The general purpose of context labels is, as far as I can discern from what others have said, to specify the context in which a specific sense applies. Presumably, it is not understood in that sense in other contexts. However, there are a few systemic problems:

Context labels add categories that do not indicate this restricted context. Category:Physics, which is added when you put {{lb|xx|physics}} on a sense, has nothing to do with restricted usage. Instead, it's just a general category where all terms related to the topic of physics can go. As a consequence, some editors are led to think that context labels are just a fancy means of putting entries in topical categories.
Worse still, some context labels put entries into "set"-type categories, but display a topical context label. {{lb|xx|particle}} puts entries in Category:Subatomic particles while showing "physics". This is confusing when used on very widespread terms like electron, which are used far outside the "physics" context.

We already have "slang" categories, like those in Category:English slang, but we have none for jargon or restricted-context senses that are not slang. However, I think these are sorely needed. It is very valuable to distinguish senses used only in physics, from those related to physics. What can be done to remedy this situation? —CodeCa t 20:25, 1 September 2016 (UTC)[reply]

I would favor using longer and more explanatory names for topical categories. I'll give a few examples. Feel free to suggest any changes.

"names of" (proper noun examples)

"names of" (place names -- subdivision(s) if they exist, country)

Category:en:Texas → Category:English names of places in Texas, USA
Category:en:Ontario → Category:English names of places in Ontario, Canada
- Category:en:Cities in Ontario → Category:English names of cities in Ontario, Canada (if this level of granularity is wanted, not just "names of places")
Category:en:Municipalities in Rio de Janeiro, Brazil → Category:English names of places in Rio de Janeiro, Brazil
- Category:English names of municipalities in Rio de Janeiro, Brazil (if this level of granularity is wanted, not just "names of places")

"names of" (common nouns) (are those acceptable?)

Category:en:Dogs → Category:English names of species of dogs

"relating to" (or "related to"?)

"jargon"

Category:en:Medicine → Category:English medicine jargon
Category:en:Anatomy → Category:English anatomy jargon
create Category:English physics jargon if needed
create Category:English psychology jargon if needed

--Daniel Carrero (talk) 21:16, 1 September 2016 (UTC)[reply]

I've been "guilty" of using the context labels to categorize items, and don't agree with the current strict usage policy. The example given in WT:ELE is

{{lb|en|informal}} An [[informant]] or [[snitch]].

It says "Such labels indicate, for example, that the following definition occurs in a limited geographic region or temporal period, or is used only by specialists in a particular field and not by the general population". Informal language however is used by large parts of the general population.

Using category links to categorize is just very awkward, they're invisible and tend to be scattered around the wiki code, at the bottom of the page or somewhere else, and have maintenance problems (forgetting to remove the link when the definition is removed/changed). Conversely, labels are close to the definition, and if the label is removed then the category is removed as well. – Jberkel (talk) 11:12, 8 September 2016 (UTC)[reply]

For French Verbs: Displaying participles in the header

I'm copying what I wrote on the discussion page for {{fr-verb}}, as I forgot that Mglovesfun was no longer active:

Would it be easy enough to have {{fr-verb}} display in a way similar to {{pt-verb}} and {{es-verb}}? This would increase consistency between French and other languages on Wiktionary (including English, Spanish, Latin, and Portuguese), which would be a big plus. I would suggest including the present and past participles. I would do this myself, but I'm not very technologically inclined.... I would love to see it implemented, though! Andrew Sheedy (talk) 01:34, 2 September 2016 (UTC)[reply]

Mglovesfun is active. His username is Renard migrant.

I'm mildly in favor. It should be Luacized as we already have a module that generates most verb forms. And I can't do that, I'm afraid. Renard Migrant (talk) 17:26, 5 September 2016 (UTC)[reply]

I generally oppose copying inflection information from inflection tables. I prefer the format used by Dutch verbs (lopen) where principal parts are shown when the table is collapsed. —CodeCa t 17:28, 5 September 2016 (UTC)[reply]

I suppose that's a workable option, but I would much prefer that all the Romance languages be consistent between each other , given their similar grammar, etc. Andrew Sheedy (talk) 17:59, 5 September 2016 (UTC)[reply]

Proto-Celtic verb lemmas

@CodeCat, Victar, UtherPendrogn, Nayrb Rellimer, Florian Blaschke, and anyone else who cares: Right now we have only two Proto-Celtic verbs, *ber- (which uses the stem as the lemma) and *brusū (which uses the 1st person singular present as the lemma). Does anyone object to my settling on the 3rd person singular present as the lemma form for Proto-Celtic verbs? That's what we're already using for verb lemmas for Proto-Celtic's ancestor (Proto-Indo-European) as well as for its best attested early descendant (Old Irish). This would entail moving *ber- to *bereti and *brusū to *bruseti. Is that OK with everyone? —Aɴɢʀ (talk) 17:29, 2 September 2016 (UTC)[reply]

What is used as the lemma for modern Celtic languages? --Wiki Tiki 89 17:34, 2 September 2016 (UTC)[reply]

The imperative for the modern Goidelic languages, the verbal noun for the modern Brythonic languages. —Aɴɢʀ (talk) 18:40, 2 September 2016 (UTC)[reply]

That seems a little strange, but then what do I know. In any case, I definitely support your proposition. --Wiki Tiki 89 18:44, 2 September 2016 (UTC)[reply]

What about the old Brythonic languages? WT:Lemmas has nothing. —CodeCa t 18:45, 2 September 2016 (UTC)[reply]

I know Welsh mostly descends from 3.sg. --Victar (talk) 18:57, 2 September 2016 (UTC)[reply]

I've been using the verbal noun for Middle Welsh, too, but I've been thinking it might be good to use the 1st person singular present (which is what the Geiriadur Prifysgol Cymru does for literary Welsh) and have the verbal noun be separate (as the verbal noun is separate for the Goidelic languages). —Aɴɢʀ (talk) 19:00, 2 September 2016 (UTC)[reply]

Support —CodeCa t 17:37, 2 September 2016 (UTC)[reply]

Abstain On one hand, PCelt's descendants are mostly 3.sg, but on the other hand, it's nice to have it in line with Latin, who's descendants are also not in 1.sg. *shrug* --Victar (talk) 18:44, 2 September 2016 (UTC)[reply]

Is there any common practice in reference works (aside from the infinitive, which some dictionaries use for everything)? Chuck Entz (talk) 19:04, 2 September 2016 (UTC)[reply]

Sounds good. I've been working on some Proto-Brythonic verbs myself. My userpage has a huge amount of WIP translations. UtherPendrogn (talk) 19:18, 2 September 2016 (UTC)[reply]

I've created a rudimentary inflection table for thematic verbs, {{cel-conj-them}}. It's still lacking many forms, as I'm not super well versed on Celtic verbs. I'd like to know especially which principal parts there are and which PIE verb stems they come from. From w:Proto-Celtic language I gather that the present, future, preterite active and preterite passive stems are principal, but their PIE origin eludes me.

The template is implemented with a module, Module:cel-verbs, and new classes can be added there fairly easily. The main issue I'm faced with is the layout of the table. The table on w:Proto-Celtic language has a lot of wasted space, I'd prefer something more compact, but I'm not sure what would work best. —CodeCa t 20:00, 2 September 2016 (UTC)[reply]

Support I don't think there's an established practice (Schumacher, for one, uses only stems), but considering Old Irish uses the 3sg too, it makes sense. I'm generally a fan of using the 3sg because it is usually the most frequent and best attested form, and in certain verbs (such as meteorological or impersonal verbs), other forms will be rare at best (though not necessarily nonexistent: for example, in the Old Lithuanian corpus a verb form like "I snow" may be attested in the context of a tale with anthropomorphised clouds). --Florian Blaschke (talk) 01:08, 3 September 2016 (UTC)[reply]

I'm a little late, but I

Support moving them to the 3sg. For what it's worth, Matasovic also only gives stems. —John C5 14:50, 7 September 2016 (UTC)[reply]

OK, I've gone ahead and moved all the verb pages (there were only four) to the third-person singular present indicative form. —Aɴɢʀ (talk) 14:46, 5 September 2016 (UTC)[reply]

I've been working on a new verb conjugation table. Please let me know what you all think. User:Victar/Template:cel-conj-table --Victar (talk) 02:40, 7 September 2016 (UTC)[reply]

I don't think it's an improvement over the existing one. —CodeCa t 12:11, 7 September 2016 (UTC)[reply]

That's seems certainly to be a tainted matter of personal opinion. --Victar (talk) 15:31, 7 September 2016 (UTC)[reply]

I definitely would not use MacBain's dictionary for anything. It's hopelessly out of date now, and wasn't all that up to date even when it was published. —Aɴɢʀ (talk) 13:54, 7 September 2016 (UTC)[reply]

Did he get everything right? Obviously not, but you cite the classic along with the modern. It's still a work in progress. --Victar (talk) 15:31, 7 September 2016 (UTC)[reply]

Please vote in "Poll: Description section"

Please vote in Wiktionary:Beer parlour/2016/August#Poll: Description section.

Current winners:

"Description" = 3 actual support votes
"Shape" = 2 actual support votes (my vote is calling it second best) + 1 vote in favour of this section "if we do have it" in the Oppose section.

If enough people prefer "Shape" instead of "Description", I can change the whole vote Wiktionary:Votes/2016-08/Description before it starts: it would become a vote for having a "Shape" section.

If more people prefer "Description" instead of "Shape", it would confirm that the vote can start as-is.

The current results are basically a tie with my "second best" comment weighing a bit in the direction of supporting "Description". If nobody else participates on the poll, I think I'll start the vote as-is. --Daniel Carrero (talk) 14:43, 5 September 2016 (UTC)[reply]

WT:NFE

The following needs to be posted on WT:NFE:

* [[Module:IPA]] and {{temp|IPA}} now support an additional <code>qual''N''=</code> parameter, to place a qualifying note before a pronunciation.

—CodeCa t 20:28, 5 September 2016 (UTC)[reply]

Done --Daniel Carrero (talk) 20:31, 5 September 2016 (UTC)[reply]

Sysop

Can I have my sysopship back please? It's getting very frustrating not being able to properly patrol or edit protected pages. I also ask for Module:links, Module:th and Module:th-translit to be restored to the version that puts the transliteration code in Module:th-translit (where it ought to be) rather than Module:links, and ask that this be enforced by all editors. There are currently negotiations for a vote for Wyang's proposal, so it would be inappropriate for him to restore his version and continue the edit war before a vote on the matter has been held. —CodeCa t 20:42, 5 September 2016 (UTC)[reply]

For the record, negotiations are happening at Wiktionary:Votes/2016-08/Enabling different kinds of romanization in different locations and the vote talk page.

I support giving back the tools to CodeCat, and to Wyang too. I support restoring modules and templates to the previous version. Whatever the merits of having two separate romanizations (I might even vote support!), I believe the status quo should prevail and that the new proposal should be properly discussed before implementation, especially in case of a huge disagreement like the one that we have now. --Daniel Carrero (talk) 20:48, 5 September 2016 (UTC)[reply]

Agreed And this also may be a good reason to implement Template Editor privileges here. —Justin (koavf)❤T☮C☺M☯ 21:55, 5 September 2016 (UTC)[reply]

Support Why was CodeCat ever desysopped? --Florian Blaschke (talk) 22:20, 5 September 2016 (UTC)[reply]

There are two things that have to happen before I restore sysop rights:

There has to be support from the community for it. This has been trickling in, and probably won't be a barrier.
I have to be convinced that both parties will refrain from any actions that might start the edit war again.

The negotiations at Wiktionary talk:Votes/2016-08/Enabling different kinds of romanization in different locations are a start, but they mostly consist of some variant of "what about this?", followed by some variant of "you're not getting my point". We need to get beyond talking past each other and start talking about serious proposals. We also need to avoid dwelling on past behavior and start discussing what the future is going to look like. Chuck Entz (talk) 22:30, 5 September 2016 (UTC)[reply]

FWIW I am OK with restoring sysop privileges, provided both Wyang and CodeCat agree not to resume edit warring. I also think that Module:links should be restored to the status quo ante, with an appropriate vote to resolve the matter. In fact I asked Dan to create this vote in order try to resolve what I thought was the root of the conflict between CodeCat and Wyang. As it happens, Wyang has objected to the vote for various reasons, some of which concern whether the issue of the vote is the right one to be voting on and some of which object to having a vote at all. The amount of contention here indicates we clearly need a vote but I'm open to rewording it. However, this issue is orthogonal to the issue of sysop privileges. Benwing2 (talk) 22:32, 5 September 2016 (UTC)[reply]

My only concern is the restoration of existing practice to the Thai transliteration module, and the elimination of custom code from Module:links. If that is accepted then there won't be any edit warring from me, though I do ask what course of action I should take if Wyang restores his version of the modules without a vote to support it. The reason the edit war happened in the first place was because Wyang kept reverting me and no steps were taken to stop him, and he ignored all attempts I made to convince him to stop and wait for consensus/vote. So if Wyang is sysopped again, there needs to be a contingency plan in case he does the same again; some kind of guarantee that others will also step in instead of just me. —CodeCa t 22:42, 5 September 2016 (UTC)[reply]

Translation: You want us to take your side on the edit war and enforce it for you. I happen to prefer your version, but this kind of talk isn't very helpful. Chuck Entz (talk) 23:27, 5 September 2016 (UTC)[reply]

Pretty much, yes. The alternative would be endorsing Wyang's edits without a vote to show such endorsement by the wider community. That doesn't seem like a proper option given how contentious the issue is. Major changes that are contentious should be voted on, yes? —CodeCa t 23:55, 5 September 2016 (UTC)[reply]

(edit conflict) One part of the problem is figuring out exactly what the status quo ante would be: this started when Wyang added his code to Module:links to implement a very useful change for Thai transliterations/romanizations. CodeCat later extensively reworked the module, in the process removing the code (I'm not sure whether she noticed the code or recognized what it was at the time). This broke a number of Thai entries and several Thai editors asked what was going on, so Wyang added the code back. It's possible that CodeCat, if she was unaware of the earlier code, thought this was something entirely new- she certainly acted as if it were. She reverted his edit, and didn't handle the dispute very well. Wyang got upset and the edit war started. Wikitiki89 came up with a compromise that moved the code out of Module:Links, which CodeCat adopted, but Wyang didn't.

Do we revert it to:

The state before Wyang's first edit? That would wipe out CodeCat's reworking of the module.
The state before Wyang's second edit? (Dan Polanski's choice, if I understand correctly). That would break a number of Thai entries.
The state after Wyang's second edit? (Wyang's choice)
The state after Wikitiki89's edit? (CodeCat's choice)

The last two are the only ones that don't break anything, and either could be considered the status quo ante, depending on how you interpret Wyang's first edit. Chuck Entz (talk) 23:15, 5 September 2016 (UTC)[reply]

I don't see any point in restoring anyone's admin rights until the substance of the disagreement is resolved. As I see it, the destructive turn the conflict took is a serious matter, affecting important core software. If the talent involved in the matter cannot resolve it, perhaps someone else should. DCDuring TALK 23:44, 5 September 2016 (UTC)[reply]

There's already a vote that attempts to propose Wyang's changes so that a formal consensus can be made. But Wyang doesn't seem very cooperative in formulating the proposal, so it's mostly stuck. Since Wyang thus has no consensus for his proposed reinterpretation of transliteration modules, the status quo remains, which is that transliteration modules provide any kind of romanisation deemed desirable. This is what my and Wikitiki's edits attempted to do. If Wyang does not agree to a vote but forces his own interpretation through edit warring, what can be done? —CodeCa t 23:59, 5 September 2016 (UTC)[reply]

@Chuck Entz: Hmm, when I wrote my comment I didn't check out the whole history carefully. Since the argument is about the presence or absence of a particular piece of Thai-specific code in Module:links, and if I'm not mistaken this didn't exist before the whole edit war started, then logically the status quo ante shouldn't include it. However, I don't completely understand the ramifications of this. Wyang obviously put the code there for a reason; but CodeCat and Wikitiki seem to believe that the same functionality can be achieved with this code in Module:th-translit. If this is true, then it should be taken out pending a vote to decide the underlying issues. Benwing2 (talk) 00:19, 6 September 2016 (UTC)[reply]

The reason the code was placed there by Wyang is because he believes that transliteration modules should only transliterate strictly: character by character. He therefore objects to the modification Wikitiki made, but at the same time, his reinterpretation of transliteration modules is not the agreed status quo. I argue that under the consensus interpretation, a vote is necessary for Wyang's proposal to restrict transliteration modules to just strict transliteration, and have an alternative module system/infrastructure for non-transliterative romanizations. I also believe that under this interpretation, the Thai transliteration code should be placed in Module:th-translit until a vote shows consensus to the contrary. And additionally, even if a vote passes to have separate infrastructures in our modules for transliteration and other types of romanization, the specific code for Thai does not belong in Module:links, but should be handled by said proposed infrastructure in a more general manner. —CodeCa t 00:34, 6 September 2016 (UTC)[reply]

There was no consensus. What is being repetitively cited as "consensus" is how people perceive romanisations from the angle of languages not making such a distinction. Truth is, appropriate and purpose-oriented romanisation has been the norm in languages with a script-pronunciation discordance, and it has been the consensus for these languages. See for example the differential use of transcriptions and transliterations ({{ko-etym-native}}) in 미끄럽다 (mikkeureopda), by User:Visviva who created the bulk of our Korean entries. The core issue is “why do the harms outweigh the benefits if we keep the transliteration and transcription modules separate for these languages”, and the conclusion from the previous discussion is: "the envisageable harm is minimal and benefits are extensive". There is a demonstratable need to maintain the systems separate - our language editors routinely apply different romanisations when editing these languages, and printed dictionaries of these languages show that authors regard that the different modes of romanisation are suited to different purposes. The issue is not whether we should implement use romanisation X in translations right now; the issue is whether the system should be maintained to take this need into consideration and not deliberately confuse the concepts "transliteration" and "transcription" (where they truly make a difference), so that future edits in these languages are not discouraged. Wyang (talk) 03:20, 6 September 2016 (UTC)[reply]

What happens now? —CodeCa t 19:57, 9 September 2016 (UTC)[reply]

Proposal: Redirect all halfwidth and fullwidth forms to their "normal" counterparts

When there are fewer active votes in the list, I'm thinking of creating a new vote for this proposal:

Redirect all halfwidth and fullwidth forms to their "normal" counterparts.

Ｘ → X
＄ → $
￤ → ¦
ﾃ → テ
ﾢ → ㄲ
etc. (Appendix:Unicode/Halfwidth and Fullwidth Forms)

I feel this should be pretty uncontroversial, but let me know if someone has a reason to keep the halfwidth and fullwidth forms.

Previous discussions:

--Daniel Carrero (talk) 00:59, 8 September 2016 (UTC)[reply]

I have a minor objection: Why are single-character half-/full-width forms more important than words spelled with them? We obviously shouldn't duplicate all our entries in half-/full-width forms, so if we can get away without those, why can't we get away without the single-character ones? --Wiki Tiki 89 14:01, 8 September 2016 (UTC)[reply]

Actually, ＣＤ was a redirect since 2013; I deleted it now. I agree with you about fullwidth words. I believe we don't want entries like ＣＤ, ＬＣＤ or ｂｙｅｂｙｅ, or even redirects like ＣＤ → CD, ＬＣＤ → LCD, ｂｙｅｂｙｅ → bye bye. But I feel that the possibility of readers searching for single fullwidth characters is higher than for words. If a person searches for "ＣＤ" and finds out that we don't have that entry, they might try searching for " Ｃ" afterwards.

According to the pageview tool (link) the fullwidth entry Ａ got 197 views in the last 6 months. Halfwidth ｱ got 12 views. It's not a terribly huge number, but I feel a redirect to the normal forms wouldn't hurt.

In general, for any redundant Unicode characters, I feel it's good to have redirects from the alt form to the "normal" form. Based on that sentiment, I created Wiktionary:Votes/2011-06/Redirecting combining characters and Wiktionary:Votes/2011-07/Redirecting single-character digraphs. Both passed, in 2011.

For better communication, I should probably create a vote with the whole idea that I have in mind. "Voting on: Allowing all single-characters full- and halfwidth forms as redirects. Forbidding full- and halfwidth words, they should not exist even as redirects." --Daniel Carrero (talk) 17:06, 8 September 2016 (UTC)[reply]

Actually, I think the problem with many of your proposals is that you create a vote too soon. We should have a long discussion first and only after the discussion has died down and some time has passed should you create a vote (if there had been enough support). --Wiki Tiki 89 17:23, 8 September 2016 (UTC)[reply]

Good point. But you can't always have a long discussion: sometimes, nobody, or just a few people, respond to my topic on the BP. If nobody else decides to weigh in on this topic about fullwidth characters, I believe I should create the vote anyway (eventually).

Concerning minor proposals that don't affect a lot of entries (I consider "redirect fullwidth characters, disallow fullwidth words" one of these) and minor policy edits that don't change actual regulations, I think it's okay to start a vote earlier than most other votes. But if creating votes too soon is a problem, I guess I could create a vote after the discussion disappears from the main Beer parlour page. Other proposals were discussed a lot (sometimes in multiple places) before the vote started. If you want, we can talk about specific past votes that I created, to see if I could have done any of them differently.

Then again, there are some proposals that were discussed already but I didn't create a vote for them. I see nothing wrong with creating a vote immediately for some of these, and pointing to the previous discussions. I may even create a new BP discussion just to point out that a new vote was created, and to see if everyone agrees with the wording of the vote. This is not the same as creating a new vote without discussion. --Daniel Carrero (talk) 18:13, 8 September 2016 (UTC)[reply]

I'll give you two rules of thumb: If the discussion is still going, it's too early to create a vote (unless it's an urgent matter). If the discussion has not had much input, try to attract more attention to it, or perhaps it is not important enough to be voted on. --Wiki Tiki 89 18:20, 8 September 2016 (UTC)[reply]

All right, I'll have this in mind: "If the discussion is still going, it's too early to create a vote (unless it's an urgent matter)."

I partially agree with this: "If the discussion has not had much input, try to attract more attention to it, or perhaps it is not important enough to be voted on." In my opinion, the proposal "redirect fullwidth characters, disallow fullwidth words" is important enough to be voted on and appear on the WT:CFI as actual criteria for inclusion/exclusion of entries, but among the things that need to be voted on, this is not very important, because it affects few entries. --Daniel Carrero (talk) 19:04, 8 September 2016 (UTC)[reply]

pirates!

FYI, September 19 is International Talk Like a Pirate Day. I would suggest doing the word-of-the-day as something pirate-related if possible. I think it would be great too if we can create an Appendix or Category of terms traditionally associated with pirate lore, such as "walk the plank." I know in my area (Maryland, USA) there are local businesses offering promotional discounts for customers who come in talking like pirates on September 19. I think a pirate vocabulary guide would be helpful not just for them, but for authors and storytellers as well. Nicole Sharp (talk) 05:24, 8 September 2016 (UTC)[reply]

Obviously we need to work on arr. DCDuring TALK 12:00, 8 September 2016 (UTC)[reply]
- For the record, arr is going to be the WOTD on September 19. --Daniel Carrero (talk) 17:32, 8 September 2016 (UTC)[reply]
I'm sure you can find a lot rummaging through Category:en:Nautical. --Wiki Tiki 89 14:10, 8 September 2016 (UTC)[reply]

Proto-Brythonic

@CodeCat, Victar, UtherPendrogn, Nayrb Rellimer, Florian Blaschke, Anglom, Angr, Chuck Entz, and anyone else who cares:

Several books on Brittonic and Neo-Brittonic suggest that the name Gwydion was "Uidgen" or "Widgen" at this point in time, not Gwidyen, as here https://en.wiktionary.org/wiki/Reconstruction:Proto-Brythonic/Gw%C9%A8d%C9%A3en . Indeed, the "gw" shift seems to have happened from NB to Old Welsh, where it became Guidgen, then in Middle Welsh Gwydyen/Gwydyon and modern Gwydion. UtherPendrogn (talk) 19:01, 9 September 2016 (UTC)[reply]

@@ Line 188: / Line 188: @@
 ::::::: The reason the code was placed there by Wyang is because he believes that transliteration modules should only transliterate strictly: character by character. He therefore objects to the modification Wikitiki made, but at the same time, his reinterpretation of transliteration modules is not the agreed status quo. I argue that under the consensus interpretation, a vote is necessary for Wyang's proposal to restrict transliteration modules to just strict transliteration, and have an alternative module system/infrastructure for non-transliterative romanizations. I also believe that under this interpretation, the Thai transliteration code should be placed in [[Module:th-translit]] until a vote shows consensus to the contrary. And additionally, even if a vote passes to have separate infrastructures in our modules for transliteration and other types of romanization, the specific code for Thai does not belong in [[Module:links]], but should be handled by said proposed infrastructure in a more general manner. —[[User:CodeCat|CodeCa]][[User talk:CodeCat|t]] 00:34, 6 September 2016 (UTC)
 :::::::: There was no consensus. What is being repetitively cited as "consensus" is how people perceive romanisations from the angle of languages not making such a distinction. Truth is, appropriate and purpose-oriented romanisation has been the norm in languages with a script-pronunciation discordance, and it has been the consensus for these languages. See for example the differential use of transcriptions and transliterations ({{temp|ko-etym-native}}) in {{ko-l|미끄럽다}}, by User:Visviva who created the bulk of our Korean entries. The core issue is “why do the harms outweigh the benefits if we keep the transliteration and transcription modules separate for these languages”, and the conclusion from the [[Wiktionary:Beer_parlour/2016/August#Wheel_War-_Action_Taken|previous discussion]] is: "the envisageable harm is minimal and benefits are extensive". There is a demonstratable need to maintain the systems separate - our language editors routinely apply different romanisations when editing these languages, and printed dictionaries of these languages show that authors regard that the different modes of romanisation are suited to different purposes. The issue is not whether we should implement use romanisation X in translations right now; the issue is whether the system should be maintained to take this need into consideration and not deliberately confuse the concepts "transliteration" and "transcription" (where they truly make a difference), so that future edits in these languages are not discouraged. [[User:Wyang|Wyang]] ([[User talk:Wyang|talk]]) 03:20, 6 September 2016 (UTC)
+: What happens now? —[[User:CodeCat|CodeCa]][[User talk:CodeCat|t]] 19:57, 9 September 2016 (UTC)
 == Proposal: Redirect all halfwidth and fullwidth forms to their "normal" counterparts ==

Wiktionary:Beer parlour/2016/September: difference between revisions

Revision as of 19:57, 9 September 2016

Contents

`{{also}}` template

Second LexiSession : paths, roads and ways

borrowing → bor

Distinction between topical and context-based usage categories?

For French Verbs: Displaying participles in the header

Proto-Celtic verb lemmas

Please vote in "Poll: Description section"

WT:NFE

Sysop

Proposal: Redirect all halfwidth and fullwidth forms to their "normal" counterparts

pirates!

Proto-Brythonic

Navigation menu

Wiktionary:Beer parlour/2016/September: difference between revisions

Revision as of 19:57, 9 September 2016

{{also}} template

Second LexiSession : paths, roads and ways

borrowing → bor

Distinction between topical and context-based usage categories?

For French Verbs: Displaying participles in the header

Proto-Celtic verb lemmas

Please vote in "Poll: Description section"

WT:NFE

Sysop

Proposal: Redirect all halfwidth and fullwidth forms to their "normal" counterparts

pirates!

Proto-Brythonic

Navigation menu

Search

`{{also}}` template