search

thunderdrop / IBMTTSDictionaries

A large, community-driven pronunciation dictionary for the IBMTTS speech synthesizer in American English
Creative Commons Zero v1.0 Universal
22 stars 9 forks source link

ENURoot.dic #6

Closed amirsol81 closed 4 years ago

amirsol81 commented 4 years ago

New words added to Root:

bytecode -> [.1bYt.2kod] counterfeit -> [.1kWn.0tR.2fIt]

the "fit" part was problematic.

fortiori -> `[.2fcr.0Si.1cr.2Y]

Part of the phrase a fortiori

inferrible -> `[.0Xn.1fR.0x.0bxl]

Alternate spelling for inferable.

apriority -> [.2e.2prY.1cr.0X.0Fi] foudre -> [.1fu.0drx]

Part of the phrase "coup de foudre" defined by many dictionaries.

countercurrents -> `[.1kWn.0tR.2kR.0Xnts]

Countercurrent was already corrected, but the plural form also needed an entry.

papabile -> [.0px.1pa.0bX.2le] cantabile -> [.0kan.1ta.0bX.2le]

amirsol81 commented 4 years ago

Folks, is this PR good? Can this be pushed/accepted on your part?

thunderdrop commented 4 years ago

Okay, I'm going to try and sort these conflicts. Are you having trouble pushing to the master branch? As stated previously, you do not need to submit pull requests if you are a collaborator, you can simply push or merge your changes directly from your local copy. Has GitHub messed with your collaborator status again? You appear as a contributor in the access page.

thunderdrop commented 4 years ago

Question: Are you aware of how the Git process actually works? You seem to be trying to do this backward. For example, you have manually put the words 'ancom' and 'ancap' in your own commit, but this isn't necessary, they're already there in the master. The project files under version control are the files you should be modifying.

The process in brief:

  1. You "git pull" the latest version of the project.
  2. You modify the files in whatever way you see fit.
  3. You "git add" the files you modified (this is known as staging them for commit).
  4. If you like, run a "git status" before committing your changes to make sure everything's ready."
  5. "git commit" Your version of the master branch (this saves a new version of the branch).
  6. "git push" your changes, so they become available remotely.

Are you having trouble doing any of this? Let me know if I can help with anything.

ultrasound1372 commented 4 years ago

The subsequent merge conflict generated by trying to bring these two together results in a file that's actually twice the size. I had to use a script to go through and fix it, and then remove the absolute varriants. There may be some duplicates...

ultrasound1372 commented 4 years ago

Fixed duplicates, thankfully there were only 3.

amirsol81 commented 4 years ago

Question: Are you aware of how the Git process actually works? You seem to be trying to do this backward. For example, you have manually put the words 'ancom' and 'ancap' in your own commit, but this isn't necessary, they're already there in the master. The project files under version control are the files you should be modifying.

The process in brief:

  1. You "git pull" the latest version of the project.
  2. You modify the files in whatever way you see fit.
  3. You "git add" the files you modified (this is known as staging them for commit).
  4. If you like, run a "git status" before committing your changes to make sure everything's ready."
  5. "git commit" Your version of the master branch (this saves a new version of the branch).
  6. "git push" your changes, so they become available remotely.

Are you having trouble doing any of this? Let me know if I can help with anything.

No, to be absolutely honest! ! My interactions with Github have been mostly NVDA bug reports in the arena of issue creation which is apparently and radically different from PR generation. So may I ask if I need to install the so-called Desktop version of Github in order to achieve these? Or can the web interface take care of it? I really want to get the hang of it if it's not super-technical.

amirsol81 commented 4 years ago

Folks, I now have the Desktop version of Github up and running. Now I know what you were talking about! I just have one question: should I just clone IBMTTSDictionaries? Or should I clone my own forked version of IBMTTSDictionaries? I think I can figure out the rest after moving past this stage as the menus and dialogs are quite logical and understandable. I also want to push my ENUmain.dic and ENURoot.dic. Thanks.

thunderdrop commented 4 years ago

@amirsol81 That's awesome! You got it right the first time, just clone the version that already exists. You're a part of the project now, so anything you want to do to the project, you do to the definitive copy. It's not as permanent as it sounds, that's the other great part of GitHub. It doesn't just make talking about code easier, it also makes editing and sharing it easier, without the worry of messing something up.

A few things to remember, if you don't mind a little advice. If you do, feel free to stop reading! :-)

  1. If you're about to commit some changes, make sure you pull first. This updates your local copy of the repository so that whatever you do to it now, you're doing to the version everyone else has. If you forget to do this, we get merge conflicts. As you've seen, they're fixable, but a bit of a pain, and they'll be a pain for you too! I'm not sure how the desktop client works as I use the command line interface, but there will probably be an option to pull the repository. You don't need to clone it every time, that makes a fresh copy. You're just pulling, or updating your copy.
  2. You might have already done this, but make sure the program knows your GitHub username and email, and is aware of any SSH keys you're using. This will save you lots of annoying, and will make sure you're properly credited for your commits and that they appear on your profile. Your email address is not shared with us.
  3. Committing is not pushing. I am seriously not meaning to condescend here, this is legitimate advice. I don't know how many people would say this, but when I was new to Git, I kept forgetting to push my commits. When they're done, they look so final and neat in the project, I would completely forget that no one would be able to see them if I just left them there. Committing means saving your changes. Pushing means uploading your changes.
  4. You're not going to break it. Seriously, go to town. That's what version control, and issues, and monthly releases are for. I hope you have as much fun with this as I do!
amirsol81 commented 4 years ago

@thunderdrop As I'm a neophyte at Github, you can't imagine how much I love and admire your comments and suggestions! Please kindly keep them coming -- I never find them condescending or prosaic.

amirsol81 commented 4 years ago

@thunderdrop Courtesy of your suggestions I started pushing files to the repo. Please let me know if I should change my style of sending/pushing/committing. Cheers.