You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I searched issues and couldn’t find anything (or linked relevant results below)
Problem
I am supporting a colleague's project to build a browser plugin for encouraging gender-neutral language in German. I was really happy to find retext-equality and think it could be a brilliant base for some of the functionality.
I want to support my colleague in adding German language to retext-equality. (Some of the contributors won't be familiar with programming and I don't speak German.) I have seen that there are similar approaches to support retext-profanities (get-alex/alex#212). I also found a relevant issue here which ended with @wooorm refactoring the code to support multiple languages (#59). This is great!
I've started following the suggestions in #59 (comment) by adding a couple of basic rules and I am now trying to add the tests. I have a few questions about the best way to do this as it will form the template for both German and adding other languages.
Solution
Should I follow the approach taken in retext-profanities and export retextEqualityDe from de.js?
How should I set up tests?
I'm not super familiar with writing tests in Javascript but it looks simple enough. That said, I would like some support in creating a template for testing non-English language patterns in retext-equality.
constfileFr=awaitretext().use(retextProfanitiesFrench).process('Merde!')assert.deepEqual(fileFr.messages.map(String),['1:1-1:6: Don’t use `Merde`, it’s profane'],'should support other languages')
This only runs for one test, whereas in retext-equality there are many tests for English.
Could someone give me an example of how a good template for the non-English tests would look?
Alternatives
I could intuitively push forward or not put in tests but I don't think either are good ideas!
The text was updated successfully, but these errors were encountered:
For Q2, maybe free make a PR with the data, then I can advise a test for that? Though, what you have for french in retext-profanities, is very similar to what I’d suggest. You don’t have to be exhaustive, a couple of tests should be enough!
Closing for now: translations are welcome — a tracking issue for german in particular is not needed (discussions are a good place for anyone who wants to do the work)
Initial checklist
Problem
I am supporting a colleague's project to build a browser plugin for encouraging gender-neutral language in German. I was really happy to find
retext-equality
and think it could be a brilliant base for some of the functionality.I want to support my colleague in adding German language to
retext-equality
. (Some of the contributors won't be familiar with programming and I don't speak German.) I have seen that there are similar approaches to supportretext-profanities
(get-alex/alex#212). I also found a relevant issue here which ended with @wooorm refactoring the code to support multiple languages (#59). This is great!I've started following the suggestions in #59 (comment) by adding a couple of basic rules and I am now trying to add the tests. I have a few questions about the best way to do this as it will form the template for both German and adding other languages.
Solution
Should I follow the approach taken in
retext-profanities
and exportretextEqualityDe
fromde.js
?How should I set up tests?
I'm not super familiar with writing tests in Javascript but it looks simple enough. That said, I would like some support in creating a template for testing non-English language patterns in
retext-equality
.The main reference I have found is that
retext-profanities
has the following test (https://github.com/retextjs/retext-profanities/blob/main/test.js#L35):This only runs for one test, whereas in
retext-equality
there are many tests for English.Could someone give me an example of how a good template for the non-English tests would look?
Alternatives
I could intuitively push forward or not put in tests but I don't think either are good ideas!
The text was updated successfully, but these errors were encountered: