Liczby, waluty i daty po polsku

Utworzyłem 3 paczki nugetowe, które być może komuś z Was się przydadzą. Wszystkie dotyczą generowania polskich słów:

Polish.NumbersInWords
Umożliwia zamianę liczb na liczby pisane słownie po polsku. Na przykład: 123.ToPolishWords() zwróci string "sto dwadzieścia trzy"
Paczka umożliwia odmianę przez przypadki i rodzaje, obsługuje liczebniki porządkowe, a także tworzenie całych zdań w oparciu o liczebnik. Na przykład jeżeli liczba jest równa 1 to zdanie może brzmieć: "Wczoraj widziałem jeden rower". Ale gdy liczba jest równa 2 to zmienia się nie tylko liczebnik, ale też całe zdanie: "Wczoraj widziałem dwa rowery".

Polish.CurrenciesInWords
Paczka zamienia kwotę na kwotę pisaną słownie po polsku. Na przykład 10.25.ToCurrencyPolishWords() zwróci string "dziesięć złotych i dwadzieścia pięć groszy". Tutaj również możemy odmieniać kwotę przez przypadki i zmienić walutę.

Polish.DatesInWords
Ta paczka z kolei zamienia datę na słowa po polsku. Na przykład DateTime.Now.ToPolishWords() zwróci string "16 kwietnia 2023". Datę można odmieniać przez przypadki i modyfikować format zgodnie z własnymi preferencjami. Można na przykład zwrócić tę samą datę w postaci "szesnasty kwietnia dwa tysiące dwudziestego trzeciego roku".

Dlaczego nie paczka Humanizer? Humanizer jest świetny i obsługuje wiele języków. Niestety Humanizer nie daje sobie rady z naszym rodzimym językiem. Odmiana liczebników jest w języku polskim na tyle skomplikowana, że Humanizer działa w wielu sytuacjach błędnie i daje zaledwie ułamek możliwości w stosunku do moich paczek.

Jeżeli macie jakieś pomysły na kolejne paczki o podobnej tematyce lub znajdziecie jakieś błędy lub możliwości rozwinięcia moich paczek, to dawajcie śmiało znać.

No dobra, to ja mam parę pytań:

1. Czemu ToPolishWords(), czy ToPolish nie byłoby wystarczające?
2. Czemu takie fluent API, zamiast podawać przypadek i rodzaj w argumentach?
3. Czemu trzy oddzielne paczki? To jest tak małe, że zmieściłoby się w jednej.

Łukasz Skrzypek napisał(a):

Dlaczego nie paczka Humanizer? Humanizer jest świetny i obsługuje wiele języków. Niestety Humanizer nie daje sobie rady z naszym rodzimym językiem. Odmiana liczebników jest w języku Polskim na tyle skomplikowana, że Humanizer działa w wielu sytuacjach błędnie i daje zaledwie ułamek możliwości w stosunku do moich paczek.

No nie wiem, z tego co widzę, to Humanizer umie konwertować sposoby zapisu tekstu (pascal/upper/camel/kebab/lower), wspiera enumy, odległości w czasie, timespany, kolekcje, liczby rzymskie, czytelniejsze tworzenie dużych liczb, i wiele, wiele innych.

Humanizer jest znacznie potężniejszy i popularniejszy, ale skoro nie radzi sobie w pewnych sytuacjach, to może lepiej byłoby go poprawić, zamiast tworzyć swoje paczki?

somekind napisał(a):

No dobra, to ja mam parę pytań:

1. Czemu ToPolishWords(), czy ToPolish nie byłoby wystarczające?
2. Czemu takie fluent API, zamiast podawać przypadek i rodzaj w argumentach?
3. Czemu trzy oddzielne paczki? To jest tak małe, że zmieściłoby się w jednej.

Łukasz Skrzypek napisał(a):

Dlaczego nie paczka Humanizer? Humanizer jest świetny i obsługuje wiele języków. Niestety Humanizer nie daje sobie rady z naszym rodzimym językiem. Odmiana liczebników jest w języku Polskim na tyle skomplikowana, że Humanizer działa w wielu sytuacjach błędnie i daje zaledwie ułamek możliwości w stosunku do moich paczek.

No nie wiem, z tego co widzę, to Humanizer umie konwertować sposoby zapisu tekstu (pascal/upper/camel/kebab/lower), wspiera enumy, odległości w czasie, timespany, kolekcje, liczby rzymskie, czytelniejsze tworzenie dużych liczb, i wiele, wiele innych.

Humanizer jest znacznie potężniejszy i popularniejszy, ale skoro nie radzi sobie w pewnych sytuacjach, to może lepiej byłoby go poprawić, zamiast tworzyć swoje paczki?

Dzięki za opinię.

At 1. Myślałem nad tą nazwą trochę i doszedłem do wniosku, że słowo Words wskazuje, że chcemy otrzymać liczbę w postaci słów. Samo ToPolish mogłoby sugerować, że chcemy wykonać jakieś tłumaczenie, a tego nie robimy.
At 2. Fluent API jest bardziej uniwersalne. Poza przypadkiem i rodzajem możemy wskazać czy liczba jest liczbą porządkową i ustawić jeszcze parę innych rzeczy. Fluent API jest jednym z rozwiązań. Innym byłoby podanie długiej listy parametrów (niefajne) lub dodanie parametru w stylu IConvertConfiguration (bardziej fajne niż długa lista parametrów, ale mniej fajne niż fluentAPI :) )
At 3. Dobra uwaga, choć jeszcze się nad tym zastanawiam. Jestem ciekaw, jakie są opinie jeszcze innych w tej sprawie.

Zdaje sobie sprawę, że Humanizer jest potężny i popularny, ale przyglądałem się jego strukturze i do języka polskiego się nie nadaje. Należałoby w nim wprowadzić naprawdę sporo zmian tylko ze względu na nasz język. Nie znalazłem też paczki, która robiłaby te rzeczy, co moje. Dlatego zdecydowałem się na własne paczki.

Łukasz Skrzypek napisał(a):

At 2. Fluent API jest bardziej uniwersalne. Poza przypadkiem i rodzajem możemy wskazać czy liczba jest liczbą porządkową i ustawić jeszcze parę innych rzeczy. Fluent API jest jednym z rozwiązań. Innym byłoby podanie długiej listy parametrów (niefajne) lub dodanie parametru w stylu IConvertConfiguration (bardziej fajne niż długa lista parametrów, ale mniej fajne niż fluentAPI :) )

Nie uważam, aby "fajność" była dobrym kryterium projektowym. Chociażby dlatego, że jest to subiektywne - Ty widzisz jakąś fajność we fluent API, dla mnie to po prostu sposób zapisu.

Fluent API ma sens, gdy chcemy wykonać potencjalnie nieskończony albo długi, ale zawierający wiele opcjonalnych elementów ciąg operacji. To nie jest ten przypadek - tutaj wiesz, że chcesz podać określony rodzaj liczebnika, rodzaj gramatyczny oraz przypadek.

Jak jest sens zezwalać na taki zapis?

 123.ToPolishWords()
    .Case(Case.Genitive)
    .Ordinal()
    .Gender(Gender.Feminine)
    .Cardinal()
    .Gender(Gender.Neuter)
    .Case(Case.Instrumental);

Druga sprawa, chyba znalazłem buga w odmianie rodzaju żeńskiego:

2137.ToPolishWords()
    .Gender(Gender.Feminine)
    .Ordinal()

Zwraca:
dwie tysiące sto trzydziesta siódma

Zdaje sobie sprawę, że Humanizer jest potężny i popularny, ale przyglądałem się jego strukturze i do języka polskiego się nie nadaje. Należałoby w nim wprowadzić naprawdę sporo zmian tylko ze względu na nasz język.

Jakie zmiany masz na myśli? Pobieżnie spojrzałem na kod tej paczki, i wygląda na to, że można nadpisywać domyślne działanie dla różnych języków.

somekind napisał(a):

Druga sprawa, chyba znalazłem buga w odmianie rodzaju żeńskiego:

2137.ToPolishWords()
    .Gender(Gender.Feminine)
    .Ordinal()

Zwraca:
dwie tysiące sto trzydziesta siódma

Dzięki za znalezienie buga! Wypuściłem poprawkę.