BGS tally not tracking

[houstonderk]

Please complete the following information:

• Version: 10.0.19045
• Game Version: Odyssey
• OS: Windows 10
• OS Locale: English_US
• If applicable: Browser Chrome

Bgs worked before when doing influence missions. Did an an update and it stopped but other things like colinization tracking works. Uninstalled and reinstalled and still nothing. If I do a mission and the overlay is on and active, it goes off after completing so it doesn't show last server tick on overlay.

Logs Please attach both the EDMarketConnector.log and EDMarketConnector-debug.log if available.

You can find these logs at %TEMP%\EDMarketConnector.log and %TEMP%\EDMarketConnector\EDMarketConnector-debug.log

See Debug Log File for information on the Debug Log files

EDMarketConnector-debug.log

EDMarketConnector.log

[chennin]

I see you're on 5.13.1 - great. The error stack is in the BGS Tally, not the main EDMC code, so to help direct troubleshooting, can you please answer:

Does it work with EDMC 5.13.0 or 5.12.5?

Has the error been reported to the BGS Tally developer?

  File "C:\Users\houst\AppData\Local\EDMarketConnector\plugins\BGS-Tally\bgstally\utils.py", line 41, in __
    contents: dict[str, str] = l10n.Translations.contents(lang=lang, plugin_path=l10n_path)
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "l10n.pyc", line 130, in contents
KeyError: 'Language en not available'

[houstonderk]

I just went back to 5.12.5 and it's displaying again.

[Rixxan]

It appears that BGS Tally may be sending an invalid language string to Contents. In 5.13, EDMC is less tolerant of invalid languages being passed (See: https://github.com/EDCD/EDMarketConnector/compare/Release/5.12.5...Release/5.13.1#diff-b0cb9ea1f6c2a8b4c466a129da1be1641b4d6e77e1cb0ee981d59ed3568fd5d3L136-L137), as the Assert statements have been replaced with direct calls to display a KeyError.

"en" is not a language in context - it needs to be added in later. I'm not sure if this is a bug with the plugin, or something we need to fix in EDMC. I'll also need to fly around and try and replicate this, but I see exactly why it's hitching.

[Tomcatt]

Version: 26100.4061
Game Version: Odyssey (latest)
OS: Windows 11 Pro for Workstations
OS Locale: English_US
Browsers:  Brave, Floorp, Vaivalda

I have the same issue. Should we roll back EDMC? I think this started two updates ago.

[aussig]

This is fixed in BGS-Tally (added an explicit check for the fallback language).

But also just capturing @Rixxan 's suggestion in Discord as a potential fix within l10n.py in EDMC itself:

    def contents(self, lang: str, plugin_path: pathlib.Path | None = None) -> dict[str, str]:
        """Load all the translations from a translation file."""
        if lang not in self.available() and lang != self.FALLBACK:
            raise KeyError(f'Language {lang} not available')

[GLWine]

Missing "en.strings" file causes fallback to fail, raising KeyError

---

Description:

When the localisation system is asked to translate using lang="en" but no en.strings file is present in the L10n folder, it raises a KeyError:

KeyError: 'Language en not available'

This breaks the expected fallback logic. Instead of returning the original string or continuing gracefully, the system halts — affecting both plugins and core EDMC behavior.

---

Technical context:

In l10n.py, the contents() method checks if the requested language is available by looking for a corresponding .strings file:

if lang not in self.available():
    raise KeyError(f'Language {lang} not available')

This behavior is problematic when the requested language is the fallback language (typically "en") and the file is intentionally missing because English strings are already hardcoded.

This check also affects the translate() function, which depends on contents() and cannot transparently handle missing fallback files.

---

Expected behavior:

If the requested language is the fallback (e.g., "en") and no .strings file is found, the system should:

• Return the original string (untranslated), or
• Gracefully return an empty dictionary {} so translate() proceeds without exceptions.

---

Why this matters:

• English is the de facto default for many plugins and the base UI.
• Most plugin authors don’t include en.strings, assuming the system will fallback silently.
• This issue introduces regressions in EDMC versions ≥5.13 where the tolerance for missing language files was reduced.
• Unexpected KeyError crashes are frustrating for users and hard to trace for developers.

---

Proposed solutions:

1. Handle the KeyError in translate() Catch the error when the fallback language file is missing and return the original string.

2. Modify contents() to return {} if fallback file is missing This makes the fallback logic explicit and safe in a single place.

3. (Alternative) Document that the fallback language file must always be present — though this adds overhead and breaks expectations for many plugins.

---

Suggested patch: In l10n.py, starting around line 127:

def contents(self, lang: str, plugin_path: pathlib.Path | None = None) -> dict[str, str]:
    if lang not in self.available():
        if lang == self.FALLBACK:
            return {}
        raise KeyError(f'Language {lang} not available')

This change ensures that requests for the fallback language never cause a crash, even if the .strings file is missing.

---

Advantages of this change:

• Correct fallback behavior: Requests for the fallback language no longer raise errors, restoring expected behavior for plugins and the core app.

• Improves plugin resilience: Many plugins rely on inline English strings and don't ship an en.strings file. This fix ensures they continue working without modification.

• Avoids unnecessary boilerplate: Plugin authors won’t need to defensively wrap translation calls with try/except just to handle missing fallback files.

• Enhances maintainability and clarity: The fallback behavior is clearly handled in one place (contents()), making it easier to reason about and test.

• Reduces upgrade friction: Changes introduced in EDMC 5.13 made the system stricter. This fix helps maintain backward compatibility and prevents breakage when updating EDMC.

---

Summary:

The localisation system should gracefully handle missing fallback language files — especially for "en" — to ensure stability, compatibility, and a better developer experience. Returning an empty translation map when the fallback file is missing allows the system to continue without errors and aligns with expected behavior across most plugins.

---

Thanks for your time and for your ongoing work on this excellent project!

[Rixxan]

Staged, will include in 5.14.