Broker guide/broker data consolidation

[JamesAlfonse]

Currently there are two google sheets that have broker data/broker guides. Ideally it would be consolidated into one that gets continuously updated. This one has more up-to-date information, and this one I believe has not been updated in a while. Once consolidated, it would be easier to implement a way to search for brokers by country as suggested by @tehchives here.

As far as implementing something like that, would a table with filters and a search bar similar to the one that exists on (database.whydrs.org) work here? Or do we go a different route? @BibicJr

[JFWooten4]

🧠
Love how you emphasize the impact/benefit of this upgrade @JamesAlfonse 👏🏼
Yes, I agree that projects are the most common way for cross-repo organization.
🙌

[BibicJr]

I've been updating both spreadsheets concurrently, so they should have the same information. Although the first one you linked (drsgme translation sheet) has the additional info of what drsgme guides were translated or not.

If there's a way to do this I think this would be the best solution: I think the whydrs database spreadsheet should be the primary resource we update and the drsgme translation spreadsheet should link to the info on the whydrs database for all broker info. Then we can update just one, but are also able to keep track of the drsgme translations. I'm not sure how this would work if we were to add additional brokers/rows to one spreadsheet though.

[JamesAlfonse]

Oh! I didn't realize you were updating both concurrently. Fantastic!
I can try linking the two sheets so that your sheet gets updated with new info from the whydrs database sheet. I can also just pull certain columns and rows from one sheet so that you don't have to manage two worksheets.
I pulled a current version of the sheet and working on cleaning that up before getting an automation up and running. If there's additional brokers to add, just let me know and I can adjust the scripts. See here

Should the whole table load, or do you want pagination with 10 entries per page?

[JamesAlfonse]

@BibicJr If it works for you, I can copy your sheet into the main worksheet so that only one automation gets created

[BibicJr]

Pulling certain columns from the whydrs database would be ideal. Rows would complicate the translation links so we can ignore that, and I can always manually add extra rows.

I only ever look at the sheets themselves, so I'm not fussed about the pagination or not, but I'm guessing the pagination makes it lighter to load?

"I can copy your sheet into the main worksheet so that only one automation gets created"
Does this mean the drsgme tanslation sheet would become a new page/sheet in the whydrs database? That might make more sense logistically, I just wasn't sure if we'd be allowed to have these resources be in the same space (as drsgme is for a specific ticker it would be frowned upon by non-profit regulators/auditors (I don't know what you'd call them))

[JamesAlfonse]

Pulling certain columns from the whydrs database would be ideal. Rows would complicate the translation links so we can ignore that, and I can always manually add extra rows.

I only ever look at the sheets themselves, so I'm not fussed about the pagination or not, but I'm guessing the pagination makes it lighter to load?

"I can copy your sheet into the main worksheet so that only one automation gets created" Does this mean the drsgme tanslation sheet would become a new page/sheet in the whydrs database? That might make more sense logistically, I just wasn't sure if we'd be allowed to have these resources be in the same space (as drsgme is for a specific ticker it would be frowned upon by non-profit regulators/auditors (I don't know what you'd call them))

I see what you're saying. Yes there should be segmentation between the translations and broker data. Having two sheets would be a quick and easy way to do it, a simple formula can automatically populate rows and columns from the Broker-Data sheet into a separate Translations sheet within the same file. As long as the Google sheet is not front-facing, do you think that that would work?

I looked at the share settings for the Google sheet and it looks like these sheets are available for public viewing:

[BibicJr]

If it can be done to different sheets in different files that would be the best, but if not then it's not the end of the world.

And yeah, all of them are viewable by the public. We definitely don't want to hide this information, just limit the edit access.

[JFWooten4]

I'd be interested to see if we could preview/change all data directly in the central git repo locale, so that we aren't worrying about synchronizing between desperate sources. For instance, if we could get the guides into the same place as the database, then it could be single to cross-reference onto a shared page on the same site for the guide. Do you think that could make it easier to auto-fill the request forms as needed?