| Wiktionary:Beer parlour/2013/July Jul 4th 2013, 01:43, by DCDuring | | | | Line 44: | Line 44: | | | ::::No consequence = 2 extra keystrokes per insertion for the manual assertions, which are there "for some reason" that is evidently beyond understanding. I am getting weary of all the extra keystrokes. Where are the changes that save effort instead of costing effort? [[User: DCDuring |DCDuring]] <small >[[User talk: DCDuring|TALK]]</small > 00:03, 4 July 2013 (UTC) | | ::::No consequence = 2 extra keystrokes per insertion for the manual assertions, which are there "for some reason" that is evidently beyond understanding. I am getting weary of all the extra keystrokes. Where are the changes that save effort instead of costing effort? [[User: DCDuring |DCDuring]] <small >[[User talk: DCDuring|TALK]]</small > 00:03, 4 July 2013 (UTC) | | | ::::: If typing is so hard for you, why don't you save yourself some keystrokes and stop nitpicking? :/ {{User:CodeCat/signature}} 00:10, 4 July 2013 (UTC) | | ::::: If typing is so hard for you, why don't you save yourself some keystrokes and stop nitpicking? :/ {{User:CodeCat/signature}} 00:10, 4 July 2013 (UTC) | | | + | ::::::Because God knows where this will stop. You've caused a significant waste of keystrokes with the changes to "context". If you don't get some pushback from someone, we will end up with one baroque system after another and no actual content contributors. I feel that our previous tech-side contributors seemed to take more care to not constantly change the user interface in one petty way after another. They seemed to enjoy actually making the site easier to use. [[User: DCDuring |DCDuring]] <small >[[User talk: DCDuring|TALK]]</small > 01:43, 4 July 2013 (UTC) |
Latest revision as of 01:43, 4 July 2013 ← June · July · August → Alternative Wikidata proposal[edit] Hi! A colleague and me, we have prepared an alternative proposal for Wiktionary support on Wikidata It tries to address several problems that the former proposal had (see its comments).--Micru (talk) 15:15, 1 July 2013 (UTC) I was under the impression that this vote had been effectively superseded by Wiktionary:Votes/pl-2013-03/Japanese Romaji romanization - format and content, but Liliana and CodeCat have apparently decided that it's worth holding. Please either chime in and vote, or discuss whether this *was* actually superseded and should be shelved. -- Eiríkr Útlendi │ Tala við mig 20:21, 1 July 2013 (UTC) - The point I raised on that page is that these templates violate WT:ELE. So we should either modify that page to allow
{{ja-romaji}} to take the place of a definition line (which requires a vote like all significant changes to WT:ELE do), or we should not use this template in its current form. —CodeCat 20:25, 1 July 2013 (UTC) - As I've pointed out before, in direct reply to you, WT:ELE makes no such explicit requirement. I can see how someone might read it that way, but the text of the relevant WT:ELE section is not explicit that the wikicode needs a
#. -- Eiríkr Útlendi │ Tala við mig 20:36, 1 July 2013 (UTC) - My reading of CFI is same as the one of CodeCat. ---Dan Polansky (talk) 20:38, 1 July 2013 (UTC)
- It was not superseded. For one thing, Wiktionary:Votes/pl-2013-03/Japanese Romaji romanization - format and content does not raise the issue of whether the wikitext should contain a definition line. For another thing, even if it did, a completed vote cannot supersede a vote that is just being started. --Dan Polansky (talk) 20:38, 1 July 2013 (UTC)
- It looks like that vote doesn't even mention
{{ja-romaji}} at all, even though it's the key in this whole discussion. So it doesn't seem very relevant. Besides, the vote did not pass so it's moot. —CodeCat 20:42, 1 July 2013 (UTC)
 This bifurcated discussion feels somewhat schizophrenic. I've replied to Dan on the vote talk page; where shall we continue discussion? Ideally in one location. -- Eiríkr Útlendi │ Tala við mig 20:46, 1 July 2013 (UTC)
- Eirikr, should editors working with Japanese stop maintaining/adding romaji entries entirely and focus on kana and kanji? Convert romaji entries, which have only one value to redirects and let opponents maintain romaji, if they oppose the new structure so badly and refuse to listen to editors who actually contribute in the Japanese space. It's quite discouraging and frustrating. Just a thought. Otherwise, I strongly oppose yet another proposal to undermine our efforts. --Anatoli (обсудить/вклад) 22:49, 1 July 2013 (UTC)
-
- Actually, Anatoli, that might be exactly the answer. :)
- @CodeCat, you've put together your module for deriving romaji from a given kana string, as used by
{{ja-suru}}, for instance. Could you and/or Liliana leverage that to undertake the bot-driven creation and maintenance of JA romaji entries, in accordance with whatever the outcome is of the current formatting vote? Such entries are purely simple links with no gloss; theoretically, no human need intervene, once a bot is up and running. I've toyed with the idea of getting a bot going for this purpose before, but with the state of JA romaji entries in such flux, and with everything else going on in life, I haven't gotten around to learning everything required to make a bot.
- FWIW, my opposition is entirely because this change impacts JA editors almost exclusively, and because this requires changes in what human editors do, as romaji entries are currently entirely human-created and human-maintained. If romaji entries are instead entirely bot-maintained, my concerns evaporate, as does my opposition to the vote. -- Eiríkr Útlendi │ Tala við mig 23:03, 1 July 2013 (UTC)
- I fundamentally disagree with the notion that this "impacts JA editors almost exclusively". I think Liliana's comment on the vote talk page is apt: you want all bot operators to code their bots to account for Japanese entries using a different basic structure than other entries. - -sche (discuss) 23:17, 1 July 2013 (UTC)
- How many bots look for the specific autoformatting issues presented by
{{ja-romaji}}? The *only* concrete concern I've heard about is with regard to KassadBot. If other bots are choking on {{ja-romaji}} as well, by all means, clue me in. Otherwise, Liliana's comment is purely theoretical outside of KassadBot, and wildly exaggerated to boot -- I'm not asking 999 out of 1000 computer users to switch from Windows to Linux, I'm asking those specific computer users out of the 999 Windows users (which is some much smaller number) to use a specific program when working with specific files. More in the mien of this thread, I'm not asking all bot operators to completely rewrite their bots on a completely different platform with a completely different coding paradigm, and instead I'm asking those bot operators whose bots choke on {{ja-romaji}} to add a few lines of logic to handle this specific case. -- Eiríkr Útlendi │ Tala við mig 23:26, 1 July 2013 (UTC) - A couple of things:
- If you make a pause in contributing Romaji for a while, you may create more content-having Japanese entries.
- Now that they are content-free, Romaji entries can be created by a bot, so if humans stop creating them manually, that will actually save human effort. If the editors previously contributing Romaji are no longer enthusiastic about Romaji, new editors will appear. After all, the only thing it takes to create Romaji with a definition line in the wiki text is to expand the current template with "subst:".
- Having unified formatting helps all sorts of ad-hoc reporting over a dump using such tools as grep, sed, awk, perl oneliners and the like, regardless of whether current bots choke on disunified formatting. Reporting over a dump is often done without a connection to Mediawiki server and without having templates expanded. I have done such reporting and have no idea how to expand templates in a dump. Arbitrarily breaking assumptions that such ad-hoc reporting relies on is no good thing. I am talking from actual experience. --Dan Polansky (talk) 16:24, 3 July 2013 (UTC)
- Re: leaving romaji entries be for the time being, I do hope these can be bot-maintained. I will be ignoring them for the foreseeable future, other than possibly inquiring about bots.
- Re: dumps, this is very useful concrete information that either wasn't presented before, or that I missed. Without this information, I am left with the impression that this issue boils down to bot maintainers versus Japanese editors, which isn't a very useful mental model. Thank you for explaining. -- Eiríkr Útlendi │ Tala við mig 18:05, 3 July 2013 (UTC)
Here is a discussion regarding these two templates and their corresponding categories, it was suggested that we bring it up at BP. This type of categorization is useful, because it's the only thing that we know in many cases, that the source language belongs to which one of these categories of the language family -- Old, Middle, or New. Note that this is not a purely chronological division, but also a linguistic one. Similar classification exists for other language families, such as Indo-Aryan (Old Indic, Middle Indic, Modern Indic). --Z 11:00, 2 July 2013 (UTC) - If it helps others to understand the issue, think of these categories as being analogous to "modern Germanic languages" or "Celtic from the 10th to 15th century". They are genetic groupings (like a real family) but with the addition of a time frame. —CodeCat 11:54, 2 July 2013 (UTC)
Is it ok to replace gender templates with Template:g?[edit] A week ago I made a post at Wiktionary:Beer parlour/2013/June#Propose to use a single template for genders, but that didn't receive any attention so I was worried that if I started replacing things, others would complain. So I am now explicitly asking if it's ok to do this. Basically, all remaining transclusions of gender templates would have {{g}} prefixed to them, so that instead of the variety of templates we currently still have ({{m}}, {{f}} and so on), there would be only this one. This template would be used only in entries themselves; in templates you'd just invoke Module:gender and number directly. This change will have some consequences for scripts and bots that still use the old templates, but they will probably not be orphaned and deleted for some time, so there is no sudden rush to fix everything yet. —CodeCat 14:11, 3 July 2013 (UTC) - What are the consequences to users, contributors, and template writers in terms of appearance, performance (eg, download time), keystrokes required, etc. If there are costs, what are the offsetting benefits and to whom?
- Also, do you have a system for converting wikicoded genders, eg ''f'' to whatever your desired gender formatting approach is right now? DCDuring TALK 14:23, 3 July 2013 (UTC)
- There are no consequences at all to users or template writers. This change applies only to cases where these templates are placed directly in entries for some reason. All that changes is that you write
{{g|f}} instead of {{f}} if you want to put a gender in an entry. But even that is pretty rare, because most of the time you will use a headword-line template like {{head}} or {{fr-noun}}, which have their own support for genders and therefore these templates are not placed in the entry itself but are handled internally by the template. There is nothing to be done for things like ''f'', although of course it is probably desirable to convert those to another format (like the one I propose) at some point. But finding that will be hard, it would probably need someone to go through a dump (which I'm not experienced with) to find and list all the instances. —CodeCat 14:36, 3 July 2013 (UTC) - I've made a list of all pages that use ''f'', ''m'', ''n'', ''c'', ''p'' or ''pl'': Wiktionary:Todo/Non-templatised genders. There may be uses of those strings that shouldn't be templatised, so some human inspection of them is necessary before any mass/automated changes are undertaken. - -sche (discuss) 21:26, 3 July 2013 (UTC)
- No consequence = 2 extra keystrokes per insertion for the manual assertions, which are there "for some reason" that is evidently beyond understanding. I am getting weary of all the extra keystrokes. Where are the changes that save effort instead of costing effort? DCDuring TALK 00:03, 4 July 2013 (UTC)
- If typing is so hard for you, why don't you save yourself some keystrokes and stop nitpicking? :/ —CodeCat 00:10, 4 July 2013 (UTC)
- Because God knows where this will stop. You've caused a significant waste of keystrokes with the changes to "context". If you don't get some pushback from someone, we will end up with one baroque system after another and no actual content contributors. I feel that our previous tech-side contributors seemed to take more care to not constantly change the user interface in one petty way after another. They seemed to enjoy actually making the site easier to use. DCDuring TALK 01:43, 4 July 2013 (UTC)
 |
