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.

@@ -14,0 +15,2 @@
+<re_restr>駄目で元々</re_restr>
+<re_restr>駄目でもともと</re_restr>
@@ -17,0 +20 @@
+<re_restr>ダメで元々</re_restr>

I agree with Stephen, it's the set-up that makes the most sense to me.

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.

豚カツ	73614	3.0%
豚かつ	12869	0.5%
とんカツ	7916	0.3%  <- standard reading
とんかつ	1941006	79.7% <- most common surface form
トンカツ	400020	16.4%

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.

@@ -12,0 +13,3 @@
+<r_ele>
+<reb>だめでもともと</reb>
+</r_ele>

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.

@@ -14,3 +13,0 @@
-<reb>だめでもともと</reb>
-</r_ele>
-<r_ele>
@@ -18 +14,0 @@
-<re_nokanji/>

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.

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.

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
╰─ーーーーーーー─┴───────┴───────╯

@@ -15 +14,0 @@
-<re_restr>駄目で元々</re_restr>
@@ -19 +18 @@
-<re_restr>ダメで元々</re_restr>
+<re_nokanji/>

Aligning

@@ -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>

Seen in a game.

@@ -8,0 +9,3 @@
+</k_ele>
+<k_ele>
+<keb>駄目でもともと</keb>

Entry created