Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat/langcode_utils #5

Merged
merged 6 commits into from
Apr 16, 2022
Merged

feat/langcode_utils #5

merged 6 commits into from
Apr 16, 2022

Conversation

NeonJarbas
Copy link

@NeonJarbas NeonJarbas commented Jan 26, 2022

adds 2 new utilities pronounce_lang and extract_langcode

Copy link
Member

@NeonDaniel NeonDaniel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would maintaining tuples that are parsed into dicts at language load be easier to maintain? Just thinking about maintaining 2x dicts for each language

@ChanceNCounter
Copy link

I've been out for hours, and we all arrived so very simultaneously the timestamps made me think something was wrong with my clock.

I love it, but I agree with Daniel that the collections should be assembled from common data rather than maintaining two. The functions could return from that. I'd wanna think about it, but I don't think it would need to be localized at that point, either.

@NeonDaniel
Copy link
Member

NeonDaniel commented Jan 26, 2022

I love it, but I agree with Daniel that the collections should be assembled from common data rather than maintaining two. The functions could return from that. I'd wanna think about it, but I don't think it would need to be localized at that point, either.

I think the names should remain localized (es should return "Spanish" for en and "Español" for es)

@ChanceNCounter
Copy link

Indeed. I meant as in the localized function wrapper. There probably doesn't need to be a distinct function in the Spanish parsers if the top level function can return the entry from common data and the lang code.

@JarbasAl
Copy link
Member

JarbasAl commented Feb 1, 2022

should i just move it to a .json resource file like is being done for other utils like the normalizer? that was the direction lingua franca was going, makes it easy to support new langs by sharing code and treating things as data when algorithms can be shared. our architecture allows easy subclassing to account for edge cases as is done with the normalizer

@NeonDaniel
Copy link
Member

json or yaml resources I think make sense for easier updates in general (this really is data, not code)

@JarbasAl JarbasAl added the enhancement New feature or request label Feb 22, 2022
@codecov
Copy link

codecov bot commented Apr 11, 2022

Codecov Report

❗ No coverage uploaded for pull request base (dev@9ea4bb3). Click here to learn what that means.
The diff coverage is n/a.

@@          Coverage Diff          @@
##             dev      #5   +/-   ##
=====================================
  Coverage       ?   0.00%           
=====================================
  Files          ?      62           
  Lines          ?   15439           
  Branches       ?       0           
=====================================
  Hits           ?       0           
  Misses         ?   15439           
  Partials       ?       0           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9ea4bb3...75553aa. Read the comment docs.

@JarbasAl JarbasAl marked this pull request as ready for review April 11, 2022 16:31
@JarbasAl JarbasAl requested a review from NeonDaniel April 11, 2022 16:31
more tests

dialect support

langs.json resource file
@JarbasAl JarbasAl merged commit fd75928 into OpenVoiceOS:dev Apr 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants