jmdict
2127720
Active
(id:
2221461)
<entry id="2221461" stat="A" corpus="jmdict" type="jmdict">
<ent_corp type="jmdict">jmdict</ent_corp>
<ent_seq>2127720</ent_seq>
<k_ele>
<keb>駄目で元々</keb>
</k_ele>
<k_ele>
<keb>ダメで元々</keb>
</k_ele>
<k_ele>
<keb>駄目でもともと</keb>
</k_ele>
<r_ele>
<reb>だめでもともと</reb>
</r_ele>
<r_ele>
<reb>ダメでもともと</reb>
</r_ele>
<sense>
<pos>&exp;</pos>
<xref type="see" seq="2127710">駄目元</xref>
<gloss>giving something a try because it will not do any harm</gloss>
</sense>
<info>
<audit time="2007-01-21 00:00:00" stat="A">
<upd_detl>Entry created</upd_detl>
</audit>
<audit time="2018-01-30 11:16:27" stat="A" unap="true">
<upd_refs>Seen in a game.</upd_refs>
<upd_diff>@@ -8,0 +9,3 @@
+</k_ele>
+<k_ele>
+<keb>駄目でもともと</keb></upd_diff>
</audit>
<audit time="2018-01-31 05:36:50" stat="A">
<upd_uid>rene</upd_uid>
<upd_name>Rene Malenfant</upd_name>
<upd_email>...address hidden...</upd_email>
</audit>
<audit time="2020-07-15 21:36:24" stat="A">
<upd_uid>jwb</upd_uid>
<upd_name>Jim Breen</upd_name>
<upd_email>...address hidden...</upd_email>
<upd_detl>Aligning</upd_detl>
<upd_diff>@@ -24 +24 @@
-<gloss>giving something a try because one has nothing to lose</gloss>
+<gloss>giving something a try because it will not do any harm</gloss></upd_diff>
</audit>
<audit time="2023-01-22 01:09:37" stat="A" unap="true">
<upd_name>Stephen Kraus</upd_name>
<upd_email>...address hidden...</upd_email>
<upd_refs>Google N-gram Corpus Counts
╭─ーーーーーーー─┬───────┬───────╮
│ 駄目で元々 │ 3,646 │ 15.6% │
│ ダメで元々 │ 4,197 │ 18.0% │
│ 駄目でもともと │ 3,626 │ 15.5% │
│ だめでもともと │ 4,444 │ 19.0% │
│ ダメでもともと │ 7,452 │ 31.9% │ - nokanji; dropping other restrictions
╰─ーーーーーーー─┴───────┴───────╯</upd_refs>
<upd_diff>@@ -15 +14,0 @@
-<re_restr>駄目で元々</re_restr>
@@ -19 +18 @@
-<re_restr>ダメで元々</re_restr>
+<re_nokanji/></upd_diff>
</audit>
<audit time="2023-01-23 01:11:27" stat="A" unap="true">
<upd_uid>robin1354</upd_uid>
<upd_name>Robin Scott</upd_name>
<upd_email>...address hidden...</upd_email>
<upd_detl>Even after the policy change, we haven't been removing the restrictions in cases like this – where there are additional (non-hidden) readings that differ only in the type of kana used (but that we want to keep because they're common surface forms).
My first thought was that [nokanji] on ダメでもともと is wrong because it has a corresponding kanji form: ダメで元々. But keeping the restrictions seems inconsistent with our simplified readings policy.
I suppose the argument for using [nokanji] is that だめでもともと and ダメでもともと have the same pronunciation and therefore the latter should just be considered an additional surface form as opposed to a separate reading.
This affects a huge number of entries so we need to decide on a consistent approach.</upd_detl>
</audit>
<audit time="2023-01-23 02:08:02" stat="A" unap="true">
<upd_name>Stephen Kraus</upd_name>
<upd_email>...address hidden...</upd_email>
<upd_detl>I don't mind too much either way. I just want to note that the reason I edited this entry was that 駄目でもともと wasn't included in the reading restrictions, so it technically didn't have an assigned reading. I think the old way is fine too, but it's definitely harder to edit and requires a lot of diligence.</upd_detl>
</audit>
<audit time="2023-01-23 04:21:23" stat="A" unap="true">
<upd_uid>jwb</upd_uid>
<upd_name>Jim Breen</upd_name>
<upd_email>...address hidden...</upd_email>
<upd_detl>My inclination is to have ダメでもともと as the only reading.
The [nokanji] tag is really intended for cases where a kana form, usually katakana, typically is not associated with a kanji form. That doesn't really apply here.</upd_detl>
<upd_diff>@@ -14,3 +13,0 @@
-<reb>だめでもともと</reb>
-</r_ele>
-<r_ele>
@@ -18 +14,0 @@
-<re_nokanji/></upd_diff>
</audit>
<audit time="2023-01-24 01:00:53" stat="A" unap="true">
<upd_uid>robin1354</upd_uid>
<upd_name>Robin Scott</upd_name>
<upd_email>...address hidden...</upd_email>
<upd_detl>We can't do that because 駄目 is a native Japanese word and we only use katakana for loan words.
The simplest solution is to make ダメでもともと search-only, but we wouldn't ordinarily hide a form with 32% of the total ngram counts – the most common form in this case.
This approach is even less attractive for an entry like 豚カツ (see n-grams above).
Using [nokanji] might be the least worst option, odd as it looks. We could also just drop the restrictions so that all the readings are associated with all the kanji forms.
None of the these options feels ideal but we have to pick one.</upd_detl>
<upd_refs>豚カツ 73614 3.0%
豚かつ 12869 0.5%
とんカツ 7916 0.3% <- standard reading
とんかつ 1941006 79.7% <- most common surface form
トンカツ 400020 16.4%</upd_refs>
<upd_diff>@@ -12,0 +13,3 @@
+<r_ele>
+<reb>だめでもともと</reb>
+</r_ele></upd_diff>
</audit>
<audit time="2023-01-24 01:54:48" stat="A" unap="true">
<upd_name>Stephen Kraus</upd_name>
<upd_email>...address hidden...</upd_email>
<upd_detl>I don't like this setup because we end up with 3 x 2 = 6 headwords. Many apps will display all six forms to users.
FWIW, I don't see anything odd about having ダメでもともと as [nokanji]. I think it's consistent with how many other entries are handled. For example, we have アリ as [nokanji] in the entry for 蟻. Apps generally just display these [nokanji] readings as extra surface forms.</upd_detl>
</audit>
<audit time="2023-01-24 02:51:25" stat="A" unap="true">
<upd_name>Marcus Richert</upd_name>
<upd_detl>I agree with Stephen, it's the set-up that makes the most sense to me.</upd_detl>
</audit>
<audit time="2023-01-24 04:53:19" stat="A">
<upd_uid>jwb</upd_uid>
<upd_name>Jim Breen</upd_name>
<upd_email>...address hidden...</upd_email>
<upd_detl>To me having a [nokanji] is odd because ダメでもともと IS the reading of ダメで元々.
I suspect the only workable solution is to go back to having restrictions. I'll set it up, approve to shrink the queue and reopen.</upd_detl>
<upd_diff>@@ -14,0 +15,2 @@
+<re_restr>駄目で元々</re_restr>
+<re_restr>駄目でもともと</re_restr>
@@ -17,0 +20 @@
+<re_restr>ダメで元々</re_restr></upd_diff>
</audit>
<audit time="2023-01-24 04:54:16" stat="A" unap="true">
<upd_uid>jwb</upd_uid>
<upd_name>Jim Breen</upd_name>
<upd_email>...address hidden...</upd_email>
<upd_detl>Reopening.</upd_detl>
</audit>
<audit time="2023-01-25 02:07:17" stat="A" unap="true">
<upd_uid>Marcus</upd_uid>
<upd_name>Marcus Richert</upd_name>
<upd_email>...address hidden...</upd_email>
<upd_refs>"To me having a [nokanji] is odd because ダメでもともと IS the reading of ダメで元々."
But it isn't, not here, not since we decided to simplify the readings. The reading of ダメ is だめ. Wadoku similarly provides hiragana readings for katakana (iirc). I think it's the best and most predictable approach.</upd_refs>
</audit>
<audit time="2023-02-10 06:38:15" stat="A">
<upd_uid>jwb</upd_uid>
<upd_name>Jim Breen</upd_name>
<upd_email>...address hidden...</upd_email>
<upd_detl>OK, I'll drop the restrictions, but since ダメで元々/ダメでもともと is a valid pairing, I won't keep the [nokanji]</upd_detl>
<upd_diff>@@ -15,2 +14,0 @@
-<re_restr>駄目で元々</re_restr>
-<re_restr>駄目でもともと</re_restr>
@@ -20 +17,0 @@
-<re_restr>ダメで元々</re_restr></upd_diff>
</audit>
</info>
</entry>