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

Correctly show endonyms on all platforms #18

Closed
abettermap opened this issue Jun 23, 2020 · 67 comments · Fixed by #73 or #81
Closed

Correctly show endonyms on all platforms #18

abettermap opened this issue Jun 23, 2020 · 67 comments · Fixed by #73 or #81
Labels
effort: 3:3rd_place_medal: (high):3rd_place_medal: Put on some coffee and clear your afternoon. priority: 3 (high) Most critical. Should be completed first. type: 🐛 bug🐛 Something isn't working

Comments

@abettermap
Copy link
Contributor

Summary

Some endonyms are not rendering in certain environments. Boxes bad, characters good:

image

Tracking

Spreadsheet

Started a rough spreadsheet to keep track of which platforms struggled with which fonts. Note that rows with empty Endonyms are hidden, and the dataset is filtered down to unique Lang/Endo combos.

Results so far

Jason
  • Not seeing any problems on OSX Safari or iOS Chrome
  • ...but there are 16 endonyms not rendering correctly on OSX Chrome (or Visual Studio Code for that matter).
Other team members

Please document as you find problems, either here or in the spreadsheet.

Long-term approach

Say we get 100% of the fonts to render on all browsers and all OS's for the 4 team members. Great start, but what about actual users? How do we make sure people see what we see? Reaching out to some beta/test users is a good start, and a long-term fallback could be to include a feedback form for reporting problems (for fonts or otherwise).

Resources

https://docs.mapbox.com/help/troubleshooting/manage-fontstacks/
https://en.m.wikipedia.org/wiki/Help:Multilingual_support

@abettermap abettermap added type: 🐛 bug🐛 Something isn't working priority: 3 (high) Most critical. Should be completed first. effort: 3:3rd_place_medal: (high):3rd_place_medal: Put on some coffee and clear your afternoon. labels Jun 23, 2020
@rperlin-ela
Copy link
Collaborator

I sent an inital email on this whole topic to one contact who has worked with the development of Unicode, and this was her response: "For fonts, I would recommend Noto family, which includes most scripts in Unicode, and is cross-platform. (Github repository: https://github.com/googlefonts/noto-fonts, older website: https://www.google.com/get/noto/)
I'm not a font expert, but another option is to use webfonts, in which the webpage will serve the font (and doesn't rely having the font on one's machine to display)." She also gave me the emails of one or two other people who I can reach out to.

@abettermap
Copy link
Contributor Author

Good info. I wonder if the Noto Sans Google Font works too?

@abettermap
Copy link
Contributor Author

I looked into this a bit and Noto isn’t a single font but rather a large family with hundreds of fonts. Obviously we only need a subset of that, and even then only when a particular endonym is show, so my initial thought is to load the extra ones dynamically. I didn’t know this was possible but the browser support is actually great.

Code aside, we still have some steps to complete first:

  1. Isolate the problem children.
  2. Determine which font (Noto variation, other font, or none available) should be used to display each missing endonym.
  3. Either indicate this in the data (e.g. a simple Endonym Font column), OR
  4. ...Maintain the info elsewhere. Believe it or not we could actually use WP for this if we get that CPT plugin up and running.

4 has a better smell than 3 to me since it would not require Maya to update the GIS. One drawback might be a greater chance of error that is inherent in maintaining two separate datasets (more chance for typos). If it’s only a couple dozen records, however, I think you could keep it tight, especially if you copy and paste values from the sheet to WP rather than typing them out.

Either way I think it’s better to store this info externally to the code for the same reasons we are keeping content separate from code:

  • You would be able to edit and update without coordinating with me. If using WP then I would only need a few bits of info (e.g. URL and field names) and the code theoretically wouldn’t change after that. Same goes for Step 3 above, although no URL obviously, which could be simpler yet on my end.
  • Division of labor: since this is pretty content-focused, you could do the testing and research on the fonts and I could continue to code the app.
  • Any updates needed after August could continue to be handled the same way (e.g. new language with non-rendering endo, or same language is found to not render for a device or platform we overlooked).

Whatever the approach, I think ultimately I would just need to know these things:

  1. Language name in English
  2. Name of font to use
  3. Hopefully a URL of the font to load. I think these are typically available but if not then we could store the fonts somewhere

What’s crazy is that we need these fonts for ONE WORD. If there was a way to get only the characters needed, it would reduce the amount of loading big time. I don’t know a ton about this but might be worth looking into.

If none of this pans out for whatever reason or it’s deemed too much work in this timeframe, I think the easiest fallback is an image of the endonym (preferably SVG). This might get weird in small sizes like a results list/table, and would definitely not be accessible, searchable, or anything else text-related, but if it’s purely for display purposes in the popup/info view then it seems like the simplest approach.

That’s a lot and I’m not sure I explained clearly so holler if you need clarification, otherwise let me know what your thoughts are thus far.

@rperlin-ela
Copy link
Collaborator

This sounds like a good plan to me, with SVG's as plan B. I don't think I totally grasp where the info would live yet, or only vaguely in theory, but I can start gathering a spreadsheet or some such as follows, if I'm understanding right?

  1. Sylheti
  2. Noto Sans Syloti Nagri
  3. https://www.google.com/get/noto/#sans-sylo

@abettermap
Copy link
Contributor Author

Believe it or not I was able to load some of the problematic fonts onto Dropbox and confirm that they do indeed render:

image

but I can start gathering a spreadsheet

Any objection to using the one I created? It was intended for tracking the problematic fonts but I'm fine putting the URLs in there as well:

image

Long-term solutions

Storing fonts

Dropbox was ridiculously straightforward for storing fonts, so let me know what you think about that approach.

Tracking the problematic fonts

I'm thinking WP might be super overkill for this, and storing this info in the full dataset would be overkill in a different way: 1000+ records and only a handful with font issues would be hard to justify adding a new column since that column is returned in the dataset regardless of whether it is populated. Sorry, bad explanation, but not super important.

However, I'll still need a way to know which fonts need to be loaded behind the scenes and we still want that info to be in your hands rather than in the code (I mean you're welcome to start making Git commits, but I don't think that's the right approach here 😃 ).

So, if not in WP and not in the main codebase, maybe we could get it into a GitHub Gist. This service is free and although it was designed for showing little snippets and tutorials, there's no reason it can't be used as free file storage (specifically a .json file, such as this realistic example I created).

If you are open to learn more about this I would be happy to create a short doc on the process. It should just be a few short steps plus a couple in Dropbox, and overall comparable or less than the effort the WP plugin would've required.

Thoughts?

@abettermap
Copy link
Contributor Author

Fun fact: those non-rendering "rectangles" have a name:

image

@rperlin-ela
Copy link
Collaborator

Tofu! That's useful.

Spreadsheet looks great. Do you want us to fill in on this end, or are you already on it?

In terms of storing fonts on Dropbox and tracking the problematic fonts with GitHub Gist (based on the spreadsheet?), I'm agnostic and happy to follow your lead. Only thing I'd advocate, here as elsewhere, is to keep things as simple and self-contained as possible to avoid things breaking down the line. (We'd still be using Wordpress for the About Us page, right?)

@abettermap
Copy link
Contributor Author

abettermap commented Jul 1, 2020

Replies

Do you want us to fill in on this end, or are you already on it?

Please do. I could see this task being either party's responsibility so let me know if you feel differently, but so far I've done a good bit of research, set up the sheet, and created a tiny working demo/test, so if you don't mind then yes, please take the lead on it. It's also good for you to do it since it's good practice for Post-August Ross.

Only thing I'd advocate, here as elsewhere, is to keep things as simple and self-contained as possible to avoid things breaking down the line.

Totally agree. Fewer moving parts = better. Gist was just one option but if we get the plugin set up in #11 and it does what we want, then that would be my vote. I could also see it being used for additional non-About, non-endonym concepts like the language points labeling potential I mentioned in #38.

We'd still be using Wordpress for the About Us page, right?

Yep. If it's one big page then it can be a WP Post or Page, but if it's multiple smaller chunks then the CPT plugin might make more sense.

WP API + CPT + MB Style thought process

Not to get overly technical and ahead of myself here, but this workflow logic is fresh in my brain and will be useful if we implement this later:

  1. Create several text-only Styles set up in Mapbox Styles (one for each field we want to allow the user to choose from in a dropdown).
  2. In a Custom Post Type set up in WP (via that plugin), store the following info for each label Style:
    1. url or whatever provides a unique reference to that Style (e.g. mine is mapbox://styles/abettermap/ckc3p2nzk06io1inut7766xsa)
    2. friendly_name or pretty_name or something to denote something the user will see in the "Label by:" dropdown (e.g. "Neighborhoods").
  3. In my code, I would:
    1. Query your WP API for that particular Post Type
    2. Sort it alphabetically by pretty_name
    3. Populate the "Label by:" dropdown with that
    4. When user changes dropdown, set the labels to point to the corresponding url for that Style

I could see this one needing clarification and I think much of it would be up to @fiddleHeads once I get it set up, but curious to hear everyone's opinions.

@abettermap abettermap mentioned this issue Jul 1, 2020
5 tasks
@fiddleHeads
Copy link
Collaborator

This sounds reasonable. But I am not very excited about the idea of having to update a subset of data on WP in addition to updating the vector tile after running the language data through my whole GIS process when there are updates to the language data. Or is that not what is being proposed here? Thanks.

@abettermap
Copy link
Contributor Author

WP

Yeah your workflow already has a lot of steps, definitely don't want to add more! If I understand your question correctly then no, there is no subset. WP would just be for maintaining a simple list of url:pretty_name pairs:

url pretty_name
mapbox://styles/abettermap/ckc3p2nzk06io1inut7766xsa Endonym
mapbox://styles/abettermap/42basdnzk06io1inut7766xsa Glottocode
mapbox://styles/abettermap/42basaddj483lj1inut7766xsa Language
mapbox://styles/abettermap/24355dfdj483lj1inut7766xsa Primary Country
mapbox://styles/abettermap/42basddaj483lj1inut7766xsa Top-Level Family

Other options

JSON, stored elsewhere

...e.g. as a GitHub gist file. Discussed this w/Ross above in regards to endonym fonts, but it could be done for the MB Styles as well. This short little list is simple enough to do as JSON, just thought WP might be easier so you wouldn't need another platform.

JSON, stored in code

After reviewing the schema, however, it looks like there's only a handful of fields that will be used as labels. If that's the case and you just want me to hard-code the URLs and names in the code, that's fine too, you just won't have the simpler workflow that you would outside the code. Git + GitHub are more complex, and I'd prefer to keep the settings stuff as it relates to your end of the workflow stored outside the code.

Spreadsheet

Most convenient for you and Ross, but it would require some overkill overhead on the code side to parse that. Definitely simplest from code perspective to use JSON as that's the standard format on the web these days (RIP XML!).

Uh oh, endonyms as labels?

Not sure if this got lost or just overlooked by me, but I see that the intent is to use endonyms as map labels? I'm not sure this is possible with MB since they only allow certain fonts not true, they allow uploads too:

image

I think this will take some work regardless of who is doing it, but good to know it's doable-ish. I was under the impression that the endonym would only be shown in the popups, not the map, so my mistake there. I guess in that case we would need an MB Style for each label field that the user can choose, but for endonyms there would be either:

  1. one style per "special" font, filtered down to just the point/s that need it
  2. one style total for Endonym, with a filter for each condition that needs a special font
  3. some kind of grouping, not sure if that's how it works though:

image

Just brainstorming again but it seems like it will come up later so thought I'd get it out there.

@fiddleHeads
Copy link
Collaborator

fiddleHeads commented Jul 2, 2020

Hi Jason. Thanks. Regarding maintaining a list of "URL pretty pairs" on WP, that sounds totally fine. I think I misunderstood how we'd be using WP.

As for the endonyms as map labels, I think the idea is to emulate how the static print map displayed languages, so that the point symbology is actually replaced by the endonym itself. Here's a screenshot of how I was playing around with that possibility in Esri's WebApp Builder, although it looks like I actually left the points in, too, in this case.
endonyms

It also gets at the possibility of being able to display the language data in different ways, perhaps displayed by its endonym and then displayed as a separate layer as points. This is what I was imagining in WebApp Builder, anyway, but perhaps displaying points as endonyms is sufficient for your purposes, @rperlin-ela? I seem to recall this convo elsewhere, perhaps in the data schema, but it's worth clarifying here, I guess.

@abettermap
Copy link
Contributor Author

Points + text seems best to me. I was able to get the endonyms to show pretty easily in the MB GUI:

image

The more I play around with the MB styles, the more powerful it seems (tbf I'm used to old-school OpenLayers and Leaflet so MB is pretty next-level 🚀 ). We can go down that rabbit hole in a separate thread once I learn a bit more, but based on what I've seen so far I'm starting to think that all of the styles can be done in MB. The dynamic filtering is where it will get code-heavy, but getting the styles into long-term maintainable platform rather than code is handy on so many levels!

I think that you'll find that there will always be room for improvement on labels, especially long and complex ones, so putting those options in your hands makes a lot of sense for the long haul.

@fiddleHeads
Copy link
Collaborator

Sounds great regarding the potential of MB styles...

@rperlin-ela
Copy link
Collaborator

Update on the endonym front... we looked into it and apparently found no tofu on Chrome, Firefox, even Internet Explorer on Mac or PC besides those already noted in the spreadsheet.

@abettermap
Copy link
Contributor Author

Ok that’s not too bad then.

So can we consider that sheet to be the complete source of truth for problematic fonts then? Obviously can add more later since lots of devices and platforms out there, but let me know if the sheet as it stands provides a sufficient baseline of what we’re up against.

@abettermap
Copy link
Contributor Author

Also I see some activity in the fonts sheet including font URLs. Those are pointing to the google source but it still needs to be downloaded, unzipped, and Dropboxed (or wherever it’s being stored for the long run). You guys are handling that process, correct? I can document the Dropbox steps if needed but it’s basically just the usual upload, make sure it’s set to public, then grab the share URL, then tweak the URL to match the format I have in my two sheet entries (this makes it downloadable).

I don’t think Google Drive has a “raw” equivalent so that’s why I suggested Dropbox, but any cloud storage platform that serves raw files should work.

@rperlin-ela
Copy link
Collaborator

rperlin-ela commented Jul 7, 2020 via email

@abettermap
Copy link
Contributor Author

but should it actually just point to the .ttf

Yep! And specifically just the "Regular" version of it (aka not Bold, Italic, etc.).

Otherwise looks good?

Close, just a few things:

  1. Make sure your URLs are in this format: https://dl.dropboxusercontent.com/s/kabn5a3iaoupcgb/NotoSansSylotiNagri-Regular.ttf?dl=0, specifically the https://dl.dropboxusercontent.com/s part. The one you get when you copy from their "Share" thing points to the same file, but I think it opens in their viewer or something.
  2. Make sure the files are set to public.
  3. Test them in an Incognito Window ("Private browsing tab" on Firefox) so that you can confirm that it's not relying on your login. You should be prompted to download the .ttf file.

@rperlin-ela
Copy link
Collaborator

rperlin-ela commented Jul 7, 2020 via email

@abettermap
Copy link
Contributor Author

The URLs still had www so I did a Find & Replace. No biggie, only took a minute, and I verified the first one is working:

https://www.dropbox.com/s/d1yh2f8seympe6e/NotoSansVai-Regular.ttf?dl=0

@abettermap
Copy link
Contributor Author

abettermap commented Jul 7, 2020

Next step

...is to get them into JSON. Now that we know there are only 16ish, I really think my WP idea is overkill! JSON is kinda the lingua franca (ha!) of data formats so if we can get that somewhere then we might be able to skip the WP plugin altogether ("About" page content remains as-is as a page though).

Mind giving the GH Gist approach a try? If it seems too cumbersome we can try something else:

GH Gist steps

One-time step: start with Jason's JSON

...just to get you started. Going forward, you'd use your own.

  1. Go to my gist
  2. Edit > Select All
  3. Copy

One-time step: create your own gist

  1. Go to https://gist.github.com/ (log into GH if needed)
  2. (optional) enter a Gist description... at the top
  3. For Filename including extension..., enter bad-lang-fonts.json or whatever you want to call it
  4. Click in the text area below it (the big block of emptiness)
  5. Edit > Paste the text you copied from my gist
  6. Click Create public gist
  7. Give me the URL of the resulting page

Updating it

  1. Visit the URL from Step 7 above
  2. Click the Edit button with the pencil
  3. Make your edit/s. I suggest using a text editor like VS Code for this, but if you're careful and/or follow the next step, should be fine.
  4. Highly recommend validating it before next step. Select All the JSON, Copy, then Paste into https://jsonlint.com/
  5. Click Update public gist

@abettermap
Copy link
Contributor Author

Alternatively to editing JSON (been there, done that, not fun!), you could:

  1. maintain a CSV file, making updates as needed
  2. Select All, Copy
  3. convert to JSON: https://csvjson.com/csv2json
  4. update Gist with the result

Doesn't matter to me how you do it, I'd just like JSON as the end result. CSV-then-JSON kinda seems like the most maintainable though. It would let you sort and auto-complete a lot more easily, and it's a familiar spreadsheet format.

@rperlin-ela
Copy link
Collaborator

rperlin-ela commented Jul 10, 2020 via email

@abettermap
Copy link
Contributor Author

@rperlin-ela

If you're seeing issues with these, I mistyped a few in #69 but they're correct now on my computer, will push in another branch:

image

Other than that, can we close this monster issue?

@rperlin-ela
Copy link
Collaborator

rperlin-ela commented Sep 2, 2020 via email

@rperlin-ela
Copy link
Collaborator

rperlin-ela commented Sep 9, 2020 via email

@abettermap
Copy link
Contributor Author

Bumthang, Kurtöp, and Tshangla should also use Noto Tibetan.

No worries, I added those and also ventured to guess that Sharchop was in that party as well. Here's that whole group rendering fine now (locally on my laptop, no push yet):

image

There are also a small number where the labels for the endonym looks good on the map, but not in the UI, e.g. Molisan. Is the endonym using Noto there?

I haven't done anything special for that one, no. It's not showing tofu for me, i see this:

image

Is that not correct? If it isn't, is this (and the others) documented anywhere along with their respective Noto font? I'm not seeing Molisan in our "endos not rendering" sheet nor the "bad-fonts.json" github config (don't worry about updating the GH config anymore, we should actually just use the sheet).

@abettermap
Copy link
Contributor Author

it occurred to me that you may be asking about the heading font in general. if so then no, they headings are all using Gentium Basic. if i switch to Noto Sans it does look more legit though:

image

I'd rather not change all the headings' font just for these handful because i think the serif looks great, so looks like we're not going to squeak by so easy on the fonts after all! definitely need a list of the ones that don't look correct though.

@abettermap abettermap reopened this Sep 9, 2020
@rperlin-ela
Copy link
Collaborator

rperlin-ela commented Sep 14, 2020 via email

@abettermap
Copy link
Contributor Author

Yikes! So we're going down the road that we didn't want to go down of having to check if every endo UI instance contains an endo on the Noto list, then using a different font family. This was going to be the approach for all the Noto's until I found that I could just add all the font families, but what you're asking now is very different since it requires multiple UI changes and checks, and an additional config.

This is getting pretty unmaintainable and I'm wondering what would prevent February 2026 Ross from telling February 2026 Jason to add or change more fonts. I was on board with continuing to update your config with the piecemeal MB fonts and a stray UI instance, but this adds a whole new level of work and maintenance questions so let me think on that. I don't want to be maintaining your config indefinitely but I've kinda painted myself into that corner, so it may take a few days to come up with something.

@abettermap
Copy link
Contributor Author

Thinking out loud here but whatever the solution is:

  • it won't be JSON. too syntax-error-prone.
  • it won't be WP, way too tedious for you to maintain dozens of config things like that
  • it won't be a database, super overkill and too hard to set up
  • it COULD be a CSV, but it would actually be like 3-4 CSVs (UI fonts config, MB endo labels config, and UI endo heading overrides config). then you'd have 3 sheets to maintain and update, and that's 3 URLs for me to hit. sounds like a different kind of mess.

if there's a way to do it with Google Sheets without using their API, that could work. will let you know if i find something.

@rperlin-ela
Copy link
Collaborator

rperlin-ela commented Sep 14, 2020 via email

@abettermap
Copy link
Contributor Author

Is the issue mostly around sustainable maintenance going forward

that's a big part of it. as with just about any project i've ever been on (solo ones included), "just one more change, then this should be it" is kind of a mantra, only to find that it's not the case at all. it's just part of the game, hence the need for a good config-based maintainer-maintained setup. we're doing well with WP and the MB uploads, but the actual fonts, not so much.

Obviously Google Sheets would be amazing

indeed. i got a hacky/legacy approach working (google is going to deprecate this API eventually) and was able to create a sheet and massage some JSON out of it:

image

doing it the "proper" google-recommended future-proof way involves a whole lot more steps, obtaining API keys, setting permissions, and installing addl dependencies in the code, so i'm not doing that right now. will add some instructions for you below.

How bad is the actual implementation part? How much is about the 14 “IPA" ones I listed

it's worse than the other font stuff because it involves not just creating addl config like what i'm doing now, but also changing the code/UI in any place that uses Gentium and an Endonym (Details heading, popups heading, and Description modal, maybe others?), plus a check in those places to see if the Language coming in is in the list of IPAs.

it doesn't matter if it's 14 or 214, the logic/changes will be same on code side. it's just the addl overhead of changing the UI and maintaining another config.

or is it about the additional bad labels I found?

no but that was the straw that broke my developer/data-maintainer back. i don't want to keep adding to your list of fonts, especially 2 weeks after the project was supposed to be finished, so i should have stayed the course of putting it all in your hands.

at the moment i think the google sheets approach is the best bet for maintaining the giant mess of MB endo fonts, but it will still take time to implement. i will at least give you a set of instructions to start with.

I know Gentium looks great, but have to ask if the problem would go away or be significantly ameliorated if we used Noto Sans as our standard font?

yes but sacrificing aesthetics seems like a last resort. i've even had someone compliment on "nice use of serif font for heading contrast with body text". definitely don't want to scrap that one for a short list of problematic languages.

There are other IPA-compatible fonts that looks decent that linguists use all the time like Charis SIL and Doulos SIL.

why didn't we use that from the beginning then? Mark suggested Gentium so i went with that.

yes changing the heading font to one of those would fix the issue in one fell swoop, but that will potentially change our relative UI layout that is based around Gentium. think padding, margins, font size, line height. the reason i had "choose fonts" as one of our very, very first GH issues is because of that.

if the new font is very similar to Gentium in size and shape then we might get lucky so let me know which SIL to use.

For what it’s worth, I think I only see the IPA issue notably in the UI (Details panel) and in the pop-up on the map

and in the Descrip modal in the table:

image

not on the label

right, labels are all independent of UI, they are only part of MB. i've tried to explain this several times but i guess i'm not good at explaining it so my bad there.

or in the data table.

data table is not Gentium. handy tip for seeing what font is used:

  1. right-click the thing you want to look into
  2. inspect element:
    image

if you got close enough to the element, you'll see it highlighted in the Elements tab:

image

click Computed:

image

it will say at the bottom what font it's using (or trying to use):

image

@abettermap
Copy link
Contributor Author

Instructions for Sheets-based MB fonts config

Start with my sheet

It already has the right format and all the correct values (excluding the new ones you just gave me today, so be sure to add those).

Copy it from File, not your clipboard:

image

Publish it

File > Publish to web

image

image

Give me the URL

i only care about the sheet ID but you can give me the whole thing, e.g. https://docs.google.com/spreadsheets/d/17upPvfKL7TglSZKG8e-3P4YZAQ-yoAw1ZYVtf0Exb_E/edit#gid=0

Abide

  1. Don't mess with the tab/sheet name
  2. Don't mess with the column headings
  3. Don't have any whitespace after any values
  4. The values in the Language column must match your data exactly
  5. The values in the Font column must match the fonts you upload to MB exactly.

Next steps

if we are switching heading fonts then there's a chance we won't need any more config, so just let me know which SIL.

the instructions above will only affect MB labels, not the UI. that is separate config and i'd rather not get into that part tonight.

i don't have this wired up whatsoever, so you won't be able to test until then. but don't let that stop you from firing up your shiny new spreadsheet.

let me know if any of that doesn't make sense.

@abettermap
Copy link
Contributor Author

handy tables for SIL comparison: https://software.sil.org/lcgfonts/support/comparison/

image

i tried Gentium Plus but not having a bold weight is kind of a deal-breaker. the headings do not stand out at all.

and Charles looks pretty rough on the phone:

IMG_4588

Andika is a 90s party invite:

image

again would rather not sacrifice what already looks good for a handful of languages so i guess i'll just change the UI and start another config then.

@rperlin-ela
Copy link
Collaborator

rperlin-ela commented Sep 15, 2020 via email

@abettermap
Copy link
Contributor Author

sounds good. i've been looking at these Endo's in the UI day-in, day-out for like the whole summer and i don't know if i ever noticed the "bad" IPA ones. i guess i just thought the larger character was part of the font?

and yes i imagine it will take longer than a few hours. the sheets-based MB endo's may as well, but that one is more worth it to me and is something i'll take the blame for since i abandoned the approach and requested that you update like 3 different files and we didn't end up using them.

but yes to the next SOW for IPA ones. seems like something someone should have caught at least a month ago, so i'm not feeling too guilty about that one. ;)

@rperlin-ela
Copy link
Collaborator

rperlin-ela commented Sep 15, 2020 via email

@abettermap
Copy link
Contributor Author

Looks good from my phone and I’ll set up the code to use your sheet directly today so I won’t need to maintain any mb font config. Yours will supersede mine and I can just delete that one so there’s no confusion. It will be used directly as the basis of handling mb fonts.

@abettermap
Copy link
Contributor Author

ok well so much for using the legacy Google API. they are shutting it down for good in two weeks.

so now we need to go through the 500 steps to use their newer API.

@abettermap
Copy link
Contributor Author

Google setup

Alrighty @rperlin-ela, hope you've got some time on your hands. :) Got this working w/my own acct, so time to pass it on.

Your screen may look different but i'll do my best...

Initial steps

  1. Log in to google dev console: https://console.developers.google.com/
  2. Next to the logo click the dropdown (no idea what yours looks like):

image

Click NEW PROJECT:

image

Give it a Project name and stumble through the other two (sorry, not sure your screen again):

image

Click CREATE.

Enable Sheets API

If you're not redirected to the Project you just made or you just want to make sure you're there, click the dropdown-near-logo again. Now you should see the project you just made, so click it:

image

Click ENABLE APIS AND SERVICES:

image

Click Google Sheets API (search for it first if needed):

image

Enable it:

image

Credentials/access

On the right side of the screen click CREATE CREDENTIALS:

image

Ignore the dropdown and click API key:

image

Give it a Name:

image

Under Application restrictions click HTTP referrers (web sites):

image

Under Accept requests enter each of these values (hit Enter to add one):

http://localhost:3000/*
http://lampel-2.local:3000/*
https://*.netlify.app/*
https://map.languagemapping.org/*

image

Click API restrictions:

image

Choose "Google Sheets API" under API restrictions:

image

should look like so after clicking it:

image

Click the Create button below it. (sorry i clicked before getting screenshot)

Send me the key VIA EMAIL

Click the little copy button next to the Key, then send it to me via email:

image

If problems

The whole goal here is just to get an API key so i'd say if you run into obstacles then just start a fresh project. If you run into obstacles a second time, let me know where/what happened.

Buena suerte!

@rperlin-ela
Copy link
Collaborator

rperlin-ela commented Sep 15, 2020 via email

@abettermap
Copy link
Contributor Author

that's the big one, and to fix the ipad logo overlap.

i've got a much longer list going, will whittle it down to some essentials.

Sheets-based config is working like a champ. so much easier to edit in there than 100+ lines of JSON, which is what i just removed from the code. i should've went with this from the onset, oh wells. if we need any other table-ish config that you control, this would be the way to go. the chaos of the steps above is a one-off, and once you have a key you can use it for any sheet.

@abettermap
Copy link
Contributor Author

FYI the current deploy MB fonts are not working because I need to give the API key to Maya to add in Netlify. I'm going to wait until I get yours working locally though so that I don't have to ask her to do it a second time (as in give her my key and then yours).

Will let you know when it's wired up.

@abettermap
Copy link
Contributor Author

confirmed that they are working, or at least Ge' ez which i tested:

image

i absolutely love that this is all in your hands now. big win!

@rperlin-ela
Copy link
Collaborator

rperlin-ela commented Sep 17, 2020 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort: 3:3rd_place_medal: (high):3rd_place_medal: Put on some coffee and clear your afternoon. priority: 3 (high) Most critical. Should be completed first. type: 🐛 bug🐛 Something isn't working
Projects
None yet
3 participants