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

#229 #96 adds french azerty and reduces JSON sizes #236

Merged
merged 7 commits into from
Oct 18, 2022

Conversation

andrewtavis
Copy link
Member

@andrewtavis andrewtavis commented Oct 17, 2022

What's in here:

  • All JSON files have had their indentation removed to reduce their filesizes (no need to check)
  • Changelog updates
  • Renames the French keyboard French AZERTY and adds French QWERTY
    • I made individual interface files that define the keys for each, which is then referenced within a common interface file that defines things like command button titles, alternate keys for long presses, etc (see setFRKeyboardLayout)
    • References to French are fixed throughout the project
  • Fixes the ´ character on French keyboards
    • Also includes making sure it's sized correctly and doesn't shift with the letter keys

@andrewtavis andrewtavis mentioned this pull request Oct 17, 2022
2 tasks
@wkyoshida
Copy link
Member

🙌 will take a look at this!

@andrewtavis
Copy link
Member Author

andrewtavis commented Oct 17, 2022

Ah I forgot that you need to be a collaborator for me to request a review :) Let me know if that's of interest and we can definitely make that happen after a couple of code contributions 😊 Thanks for taking a look!

@andrewtavis andrewtavis linked an issue Oct 17, 2022 that may be closed by this pull request
2 tasks
Copy link
Member

@wkyoshida wkyoshida left a comment

Choose a reason for hiding this comment

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

I didn't go over the JSON files 👀 but the French keyboard changes are looking good! Couple minor comments that I had ⬇️

@@ -236,7 +239,7 @@ func returnConjugation(keyPressed: UIButton, requestedForm: String) {
/// Returns the conjugation state to its initial conjugation based on the keyboard language.
func resetVerbConjugationState() {
conjViewShiftButtonsState = .leftInactive
if controllerLanguage == "French" {
if ["French_AZERTY", "French_QWERTY"].contains(controllerLanguage) {
Copy link
Member

Choose a reason for hiding this comment

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

Could it make sense to initialize ["French_AZERTY", "French_QWERTY"] globally perhaps? I'm thinking that in doing so, if a new layout variant is added, one wouldn't have to remember to make edits to multiple locations. Could then just update in one location.

Referring to the other changes made on L295 and L314 in this same file, for instance.

Copy link
Member Author

Choose a reason for hiding this comment

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

Makes sense :) I think the easiest way of doing this right now that would allow for variants to be added without needing to change them is to just pattern match on the string in the following way:

controllerLanguage.prefix("French".count) == "French"

Copy link
Member

Choose a reason for hiding this comment

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

Love it 👍 Yep, I agree! I think that'd be a pretty clean way of doing it if the variants all begin with the target language descriptor

Copy link
Member Author

Choose a reason for hiding this comment

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

Will have to, but I think it makes sense to do it that way anyway 😊

CHANGELOG.md Outdated Show resolved Hide resolved
func setFRKeyboardLayout() {
getFRKeys()
Copy link
Member

Choose a reason for hiding this comment

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

Oh I was thinking that getFRKeys() might be able to stay in this file, maybe no? Could it work to change getFRKeys() to take in a parameter for FrenchKeyboardConstants and then the if statements would just call it with either the AZERTY or QWERTY constants sent in? Perhaps you did try that already and there's just something I'm overlooking

Copy link
Member Author

Choose a reason for hiding this comment

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

I made the decision to not include this with an eye on adding future ones that might have more distinct variations in the future, but thinking about it now I can't think of any that would be sooo different that we wouldn't be able to handle their variations in conditions at the top as we do with setFRKeyboardLayout. Thanks for bringing this up 😊

Copy link
Member Author

Choose a reason for hiding this comment

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

But now I'm realizing that there actually is an issue here, as we'd need to make a var that can be assigned either of the constant enums, but then what happens is that this var would need to be instantiated with all the elements of the enums so that Swift/Xcode will know that they exist. I'm now getting errors that say that FrenchKeyboardConstants.letterKeysPhone doesn't exist. We should likely create a base enum that all the other interface variable ones are based on :) Would be a different issue though 😊

Copy link
Member

Choose a reason for hiding this comment

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

Ahh I see.. 😞 I was concerned something like that might get in the way.

Yep, I agree though. This can get refined later on in other issues, especially as work gets done on decoupling the language and the keyboard layout.

@@ -51,7 +51,11 @@ class KeyboardKey: UIButton {
self.layer.setValue(true, forKey: "isSpecial")
Copy link
Member

Choose a reason for hiding this comment

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

Just an observation on the changes in this file -

These are interesting, hmm.. 🤔 Makes sense that some keys should be ignored when it comes to upper/lower-casing. Just wondering if there could be a scenario where a key would have upper/lower-casing in one language but not in another. In that case, the logic here would depend on the target language. I'm thinking this would definitely be an edge-case, and I don't even know if it could happen 😆 , but just a thought I had.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thoughts of edge cases are much appreciated! There are all kinds of little things like that in Scribe 😊 Specifically languagesWithCapitalizedNouns, which as of now is ["German"] 😄 We try to handle them as they come up :)

Copy link
Member

Choose a reason for hiding this comment

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

Oh.. the challenges of working with multiple human languages 😆

Copy link
Member Author

Choose a reason for hiding this comment

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

Welcome to Scribe! 🤣😊

andrewtavis and others added 4 commits October 18, 2022 08:32
Co-authored-by: wkyoshida <yoshida.william@gmail.com>
…rfaceVariables.swift

Co-authored-by: wkyoshida <yoshida.william@gmail.com>
@andrewtavis
Copy link
Member Author

Thanks for the review, @wkyoshida! I'll merge this now and we can discuss a bit more in the issue 🚀

@andrewtavis andrewtavis merged commit 3fbd32a into main Oct 18, 2022
@andrewtavis andrewtavis deleted the 229-96-french-azerty-shrink-jsons branch October 18, 2022 07:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Regional keyboard variants
2 participants