Spanish Implementation

[Laifsyn]

Submitting as draft because
1-) I'm unclear how pull requests actually works
2-) I haven't properly made an Integration Test because I found it extremely un-ergonomic to constantly build the Num2Words settings after every .to_word() call

I also submitted a .devcontainer configuration because I found it extremely helpful to be able to test stuffs in a virtual environment specially so when I didn't have available a beefy-enough computer (I might've forgotten to add Rust Docs Viewer in the extensions though)

[Laifsyn]

Alright, this should be about it. (except for mod.rs because I was too lazy to undo rustfmt on that. Shame on me)
But everything should be the most minimal for the spanish implementation feature.

Rustfmt should be easily be doable in another pull request by just re-adding the rustfmt.toml file and running rustfmt against the project.

the undonde derives could be additionally done in another PR.

and optionally fix clippy warnings in another PR

[Laifsyn]

I misread the commit content. This commit should've been add missing docs

[Ballasi]

Sorry for making you go through all of this trouble! and thank you very much for taking the time to work on it, it's very kind :)

I'll see the PR more in depth this weekend! If you're not planning on redoing the derives or rustfmt, I'll take on that job once this is merged.

[Laifsyn]

I was thinking about figuring what rustfmt config was the one that onelined the chained methods and see if it was alright to disable it.

The reason is because if the method chaining gets one-lined, then the type-hint for each method return on the chain will not be hinted by rust-analyser.

but anyways, the chainings tends to be short more often than not, so the loss of the type-hint which can only be seen in an IDE isn't that relevant

[Laifsyn]

Hi, I was thinking about making a PR Benching with Criterion with another branch for benchmarks. Mainly I want to see what issues can arises when I expect merge conflicts( expecting so because I had to add some derives to do the benchmark)

The reason was to see how the spanish implementation fared because I did a fix to the unneeded 0 spam that the split_thousands() method created. (Ref: link)

[Ballasi]

Thank you again for taking the time to participate! I'm sorry I am relatively slow, I've got a lot going on lately.

Feel free to take a look at the comments I've put :)

[Ballasi]

ditto

[Laifsyn]

Ditto the pokemon?

[Ballasi]

btw, compared the results from es.rs to python num2words and see differences

I don't mind much the differences in megas as it depends a lot on the source. however mil trillones makes me wonder, is this what should actually be the number?

10000000000000
diez billones
diez trillones

100000000000000
cien billones
cien trillones

1000000000000000000
un trillón
un quintillón

1000000000000000000000 <=== here
mil trillones
un sextillón

10000000000000000000000000
diez cuatrillones
diez septillones

[Laifsyn]

What's different?. Is Mil Trillones from Python?

I followed the standard of Each thousands changes the Millard because It was a bit confusing that a Billion*1000 is called the equivalent in spanish of "thousand billions" instead of "trillion"

[Laifsyn]

https://es.wikipedia.org/wiki/Anexo:Nombres_de_los_n%C3%BAmeros_en_espa%C3%B1ol
So according to this source, it starts to jump by 1_000_000 instead of 1_000 after the trillion

As summary, English's Sextillion is 10^21
Spanish's Sextillion (according to this particular page in wiki) is 10^36

I guess it would still best to discuss with someone more familiarized with spanish, because if this really is the spanish standard, I'm pretty sure almost none will get spanish's quadrillon right (Because it actually is "A Million Trillion")

[Laifsyn]

Alright. That should be it

[Laifsyn]

Oh, btw. I'm working on translating the currencies. Might submit a commit by the end of the day

[Laifsyn]

I have a question if you can get the answer

I'll be leaving it as the first meanwhile, but should it be like the second case?

assert_eq!(
    ordinal(124_001_091_000_000_000_001),
    "ciento veinticuatrotrillonésimos milnoventa y unobillonésimos primeros"
//  "ciento veinticuatrotrillonésimos mil noventa y unobillonésimos primeros"
);

[Laifsyn]

I couldn't redo the Cardinal implementation.
Performance gains were dirt low. at about x1.02-x1.25 faster, and also the implementation looked a bit ugly. So I have no changes to the current implementation of Spanish.

[PabloGmz96]

Hey guys! Native Spanish speaker here. Is there anything that you need help with? I'd love to use this crate in a project that I'm currently developing

[Laifsyn]

Hey guys! Native Spanish speaker here. Is there anything that you need help with? I'd love to use this crate in a project that I'm currently developing

• I would like opinions on whether to support a flavor for "Semantically Incorrect" milliards.
  according to RAE, 10E9(1,000,000,000) is called "Billón", whereas in English, 10E9 is called "Trillion". Choosing to support semantically Incorrect cardinals would mean that spanish's "Billón" would be english's trillion milliards like "billón" and "trillón" in spanish are just the literal translation of english's.

• Maybe check currency, in case some currency got mistranslated.

• Support converting too big of numbers into nEm expression, i.e. 20.23E20 => veinte coma veintitrés por 10 a la 20

Priority close to 0:

• Cleanup tests & Integration Tests: Because some test cases overlaps other tests. Also I personally think they could look cleaner with some work.

Otherwise, everything should be fine. Other than big numbers which can lose precision

[PabloGmz96]

Hey @Laifsyn! I just review the "Semantically Incorrect" numbers that you mention and as far as I know almost the complete Latin-america region use those big numbers exactly in the same way as in English, so a direct translation of them should be precise enough. Later versions of this crate could include some other forms of Spanish cardinals numbers but knowing that they are rarely used this should be not a priority. But let me ask some friends in Colombia and Argentina (Countries that use particularly high number prices in the every day life) to confirm that.

In the other hand, let me test the USD and PESOS translation, those are the currencies that I'm familiar with.

And last but not least, I just want to say a big thank you to make the Spanish implementation possible!

[PabloGmz96]

Just a quick update... When using Spanish as language, the output shows the array that the code use to translate the numbers to words.

[Laifsyn]

Just a quick update... When using Spanish as language, the output shows the array that the code use to translate the numbers to words.

Thanks for finding out! I might have forgotten to test the actual binary before I uploaded