Locale Override Broken in Obsidian v1.7.3

[iiz00]

Describe the bug

The locale override feature appears to be broken in recent Obsidian insider versions (starting from v1.7.2 or v1.7.3?). This feature had been working flawlessly for years until recently in my environment. Rolling back to the public release of Obsidian seems to resolve the issue.

Steps to reproduce

1. Incorrect Daily Note Naming

   • Despite selecting Override locale in the Calendar plugin settings (in my case, overriding "system locale(ja)" to "en-sg" with filename format YYYY-MM-DD_dddd), daily notes are created using the pre-override language.
   • Example: Creates '2024-10-03_木曜日' instead of '2024-10-03_Thursday', breaking filename consistency with existing daily notes.

2. Settings Display Issues

   • The Calendar plugin settings screen randomly fails to load completely (sometimes it does load fully; specific conditions unknown).
   • Console displays the following error:

     plugin:calendar:814 Uncaught TypeError: Cannot read properties of undefined (reading 'dow')
         at CalendarSettingsTab.addWeekStartSetting (plugin:calendar:814:66)
         at CalendarSettingsTab.display (plugin:calendar:775:14)
         at t.openTab (app.js:1:3043848)
         at HTMLDivElement.<anonymous> (app.js:1:3042168)

3. File Access Issues After Plugin Reset
   • After disabling and re-enabling the Calendar plugin:
     • Settings screen loads completely
     • New issue emerges similar to Issue #373
     • New files can be created with the overridden language
     • But, attempting to open these files through Periodic Notes command results in an error
   • Console displays:

     app.js:1 Uncaught (in promise) Error: File already exists.
         at t.<anonymous> (app.js:1:732669)
         at app.js:1:237228
         at Object.next (app.js:1:237333)
         at a (app.js:1:236051)
     

• Issue can be reproduced in a new vault with only Calendar plugin and Periodic Notes plugin installed.
• Rolling back to the public release of Obsidian (v1.6.7) seems to resolve the issue.
• Based on the symptoms, it appears that recent changes in Obsidian insider versions have caused the Calendar plugin to fail when attempting to override locales.

Screenshots

Settings screen fails to show all items

Environment (please specify)

OS

Windows 11

Obsidian Version (e.g. v0.10.6)

v1.7.3 (insider)

[iiz00]

After roughly examining and testing the code,
Adding
configureGlobalMomentLocale(settings.localeOverride, settings.weekStart);
after await this.loadOptions(); on line 4428 of main.js
might have improved the situation (I haven't thoroughly verified this, so there might be other issues introduced).

[iiz00]

Hmm, even after the above, things still go wrong after restarting Obsidian... It seems that turning the Calendar plugin and Periodic Notes plugin off and on in sequence fixes it.

[ksdavidc]

also getting this.

Hmm, even after the above, things still go wrong after restarting Obsidian... It seems that turning the Calendar plugin and Periodic Notes plugin off and on in sequence fixes it.

not sure whatis meant here. could you specify? you mean calendar on and off, then periodic, or calendar off, periodic off, then calendar on and periodic on? Are you reloading after each?

[ksdavidc]

While testing another plugin, I can now verify that the settings display error is related to whether or not calendar is the visible tab on startup, per sandbox vault. if it is, no error, if it isn't, error.

[iiz00]

My current workaround for this issue is as follows:

1. Modify the main.js file of the Calendar plugin as mentioned previously.
2. After launching Obsidian, restart the plugins in this order: Calendar plugin, then Periodic Notes plugin. If the Calendar plugin's view is already displayed, restarting the Calendar plugin might not be necessary.

Here's my speculation about this bug (which may be incorrect):

• The locale override processing in the Calendar plugin seems to occur during the plugin's custom view rendering, not during plugin startup.
• In Obsidian v1.7.2, to improve startup times, view rendering is skipped when a plugin's view is not in the foreground (I haven't thoroughly investigated this). As a result, if the Calendar view is not displayed, the locale override processing doesn't occur. This leads to failures when trying to open the settings page, causing it to display only partially. It also causes plugins that use locale override, such as Periodic Notes, to malfunction.

The main.js modification mentioned above is intended to perform locale override processing during the Calendar plugin's startup. However, due to potential issues with the startup order between Calendar and Periodic Notes plugins (or perhaps other factors), it seems necessary to restart each plugin as described above for proper functionality. Creating a Templater script to automatically restart the plugins might be more convenient...
The ideal solution would be to integrate the locale override functionality (and perhaps even the Calendar and Periodic Notes features) into Obsidian's core functionality 😄

[ksdavidc]

I see very clear thank you much appreciated

…

On Mon, Oct 21, 2024, 12:44 iiz00 ***@***.***> wrote: My current workaround for this issue is as follows: 1. Modify the main.js file of the Calendar plugin as mentioned previously. 2. After launching Obsidian, restart the plugins in this order: Calendar plugin, then Periodic Notes plugin. If the Calendar plugin's view is already displayed, restarting the Calendar plugin might not be necessary. Here's my speculation about this bug (which may be incorrect): - The locale override processing in the Calendar plugin seems to occur during the plugin's custom view rendering, not during plugin startup. - In Obsidian v1.7.2, to improve startup times, view rendering is skipped when a plugin's view is not in the foreground (I haven't thoroughly investigated this). As a result, if the Calendar view is not displayed, the locale override processing doesn't occur. This leads to failures when trying to open the settings page, causing it to display only partially. It also causes plugins that use locale override, such as Periodic Notes, to malfunction. The main.js modification mentioned above is intended to perform locale override processing during the Calendar plugin's startup. However, due to potential issues with the startup order between Calendar and Periodic Notes plugins (or perhaps other factors), it seems necessary to restart each plugin as described above for proper functionality. Creating a Templater script to automatically restart the plugins might be more convenient... The ideal solution would be to integrate the locale override functionality (and perhaps even the Calendar and Periodic Notes features) into Obsidian's core functionality 😄 — Reply to this email directly, view it on GitHub <#375 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AO2Y35CAR3A2ZYD5CCHYVKDZ4R2BBAVCNFSM6AAAAABPJJSMF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRVGUYDQMJVG4> . You are receiving this because you commented.Message ID: ***@***.***>

[iiz00]

I am currently working around this problem by registering the following script in the startup script of Templater plugin in addition to the above fix.

<%*
sleep(500);
app.plugins.disablePlugin("calendar");
sleep(100);
app.plugins.enablePlugin("calendar");
sleep(500);
app.plugins.disablePlugin("periodic-notes");
sleep(100);
app.plugins.enablePlugin("periodic-notes");
%>

[Graywaren]

Not sure if it's helpful or if it should be added to this thread or not (let me know and I can move it if preferable), but I'm also getting a similar console error if the calendar is not visible on load. My error involves the Settings Search plug in, which adds a search bar to search for settings in the entire settings menu. When I attempt to search for the name of any settings from the Calendar plug-in, no results come up, so it appears that it fails at adding the settings for Calendar from this error. I confirmed that if the calendar is visible on load, then the settings do come up in it's searches and that this happens with other plug-ins that error for not being visible on load. Definitely seems to involve the new view rendering they introduced.

I'm on windows 10 and don't have Periodic Notes installed. I also didn't override any local defaults using calendar and I haven't noticed any problems viewing the calendar or any of the settings on the settings page for it.

Here's the console error in its entirety.

plugin:calendar:814 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'dow')
    at CalendarSettingsTab.addWeekStartSetting (plugin:calendar:814:66)
    at CalendarSettingsTab.display (plugin:calendar:775:14)
    at SettingsSearch.getTabResources (plugin:settings-search:229:15)
    at SettingsSearch.buildPluginResources (plugin:settings-search:129:12)
    at eval (plugin:settings-search:131:29)
addWeekStartSetting @ plugin:calendar:814
display @ plugin:calendar:775
getTabResources @ plugin:settings-search:229
buildPluginResources @ plugin:settings-search:129
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:131
setTimeout (async)
buildPluginResources @ plugin:settings-search:131
eval @ plugin:settings-search:112
(anonymous) @ app.js:1
(anonymous) @ app.js:1
(anonymous) @ app.js:1
a @ app.js:1

[ltroj]

This bug is a bit of a problem because using calendar's locale override is the one simple way to force the core plugin Templates to use a specific locale.

Would be awesome if this got fixed 🙏

[Fe1ler]

After roughly examining and testing the code, Adding configureGlobalMomentLocale(settings.localeOverride, settings.weekStart); after await this.loadOptions(); on line 4428 of main.js might have improved the situation (I haven't thoroughly verified this, so there might be other issues introduced).

I tried your advice. It worked!