Add Lazne Bohdanec waste collection schedule

[djz88]

This source adds waste collection schedule for Lazne Bohdanec in the Czech Republic. City publishes calendar via xlsx file on city webpage.

This source does:

• default automatic detection from the page
• or allows to use direct document url
• or local file in case of detection issues

I updated translation files via ./update_docu_links.py .
Also it adds testdata in tests/data/laznebohdanec.xlsx which are used by TESTCASE when run test_sources.py.

python3 custom_components/waste_collection_schedule/waste_collection_schedule/test/test_sources.py -s laznebohdanec_cz 
Testing source laznebohdanec_cz ...
  found 65 entries for Lázně Bohdaneč

[Copilot]

Pull request overview

This PR adds waste collection schedule support for the city of Lázně Bohdaneč in the Czech Republic. The source parses XLSX files containing waste collection calendars, either by automatically discovering the file URL from the city's webpage, using a direct URL, or reading from a local file.

Changes:

• Adds a new source module laznebohdanec_cz.py with XLSX parsing functionality for waste collection schedules
• Updates README.md and info.md to include Lázně Bohdaneč in the Czech Republic section
• Adds documentation in English and Czech explaining configuration options
• Updates translation files (en.json, de.json, fr.json, it.json) with UI strings for the new source
• Includes test data file (laznebohdanec.xlsx) for automated testing

Reviewed changes

Copilot reviewed 9 out of 10 changed files in this pull request and generated 8 comments.

Show a summary per file

File	Description
custom_components/waste_collection_schedule/waste_collection_schedule/source/laznebohdanec_cz.py	New source module implementing XLSX parsing for waste collection schedules with auto-discovery, direct URL, and local file support
doc/source/laznebohdanec_cz.md	Documentation for the new source in English and Czech, explaining configuration and usage
info.md	Updated to include Lázně Bohdaneč in alphabetical order in Czech Republic providers list
README.md	Updated to include Lázně Bohdaneč with documentation link in Czech Republic section
custom_components/waste_collection_schedule/sources.json	Added source metadata for laznebohdanec_cz
custom_components/waste_collection_schedule/translations/*.json	Added UI translations for source configuration in multiple languages
tests/data/laznebohdanec.xlsx	Test data file for automated testing of the parser

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[djz88]

I have fixed most of the issues mentioned above. This should also fix pipeline issues with the URL in the translatable strings.

[bbr111]

@djz88 the docs are created by running update_doc_links.py
but is looks like you used an older version of it.

git merge upstream/master into your branch
then run python3 update_docu_links.py

[djz88]

Hi, I have rebased my branch on the top of upstream/master and also re run update_docu_links.py. Hopefully it is ok now.

[bbr111]

is it really nessesarry to add .xlsx files to tests/data in master?

i didn't like it. can we use the url part for testing?

[djz88]

Well, I wanted to avoid being dependant on online fetch and have consistent testing data in case of some structural change in integration code but TESTCASE can be calle without a param and it will do autodetect of xlsx from official web (to be more resilient in case they update the file and it gets new URL). If you prefer that I don t mind removing test xlsx and keep it via autodetect. Which test do you prefer autodetect or direct document url ( can change over time and test will fail)?

[bbr111]

Just to clarify the intended behavior:

For the production variant, the default should be fetching the online resource so that we always work with the most up-to-date data.

Regarding tests, I understand the need for deterministic behavior. However, I don’t think we should commit full external source documents (e.g. original XLSX files) into the repository. If we follow that pattern for each integration, the test directory will grow with various external source files over time, which I would like to avoid from a maintenance perspective.

So from my side:

Production → default = fetch online resource

Tests → deterministic, but without versioning full external source files

Let me know if that aligns with your view.

[djz88]

I understand and I agree what you wrote above. But I did not get what I should do with TESTCASE. :)

This source has logic to parse specific xlsx file and has 3 inputs (autodetect xlsx from official page, direct document link and local file). I would go with TEST using auto fetch from official town URL and grab xlsx from there (e.g. default behaviour). Is that ok for you? Otherwise I'm not sure how else to test this source.

Well I could put test xlsx somewhere on internet and fetch it in TESTCASE but that would be more error prone raise maintenance.

[bbr111]

Thanks for the clarification.

Yes — I would be fine with using the online autodetect in TESTCASE.

My reasoning is that this source is inherently dependent on the official XLSX structure. If the city changes the format or link structure, I would actually prefer the test to fail so that we notice it immediately.

For development purposes, using a local file is absolutely fine. But I would prefer not to version the XLSX file in the repository.

So from my side:

Production → online autodetect (default)

TESTCASE → online autodetect as well

Local file → for development only, not committed

I’m aware that this introduces an external dependency in tests, but in this case I think that’s acceptable and even desirable as an early warning mechanism.

Let me know if that works for you.