Open chanpory opened 7 years ago
By the way, the code sample above is designed for reproducibility—the actual scenario @chanpory and I were seeing is:
i18n.__("foo")
from a template helper.i18n
object).The file is not the source of the inside object at any time. That means removing or editing the file will not update the actual object inside i18n. Files are cached and all that stuff. You need to remove the key yourself from the inside object using delete
Thanks for the quick response @gjuchault.
The file is not the source of the inside object at any time.
I guessed as much, I am saying that is problematic. :) The source of truth should be the file, at least locally—surely caching is not necessary then—to simplify editing. In this scenario there was no opportunity to call delete
, we were just editing HTML templates not JS. And if we had edited JS then the server would have restarted and i18n's internal state would have been purged anyway.
The source of truth should be the file
The file will not be read every time you get a value. Caching is necessary. I didn't get the part where you say you don't have any JS possibilty
The file will not be read every time you get a value. Caching is necessary.
Could you explain why this needs be the case locally, as opposed to in production?
It'd be more complex, but I could also envision a system where caching continued to be employed locally, yet the file was the source of truth—using chokidar
or something similar to watch the file and reload i18n
's internal state from the file when the latter changed.
I didn't get the part where you say you don't have any JS possibilty
In our scenario, at no time did we edit any JS. We only edited the HTML template and the localization file.
It's actually generally unclear to me where you would call delete
to clean up individual keys like in our scenario. You'd have to write a one-off delete
call only to remove it as soon as the key was gone. And when you restarted the server to make use of the delete
call, it would purge i18n
's internal state—so there wouldn't even be any more need for the delete
call, if you just deleted the line from the localization file. Much easier to just edit the localization file.
Could you explain why this is the case locally? [and next paragraph]
You're not supposed to edit a generated file by your library to change the way it works while it's on. The library generates this file.
Furthermore, reading a file is a costly operation, compared to a object getter. Using a file watcher would solve a problem that is yours and not i18n-node-2's (see the previous point).
In your scenario, you make a mistake and then you want to correct it and make i18n-node-2 refresh its cache by using a file watcher. This looks kinda weird. I'm used to reload my server whenever I make a change inside, or use something like nodemon
or others (there are plenty) to make it reload when there is a change. Did you consider using a process watcher (even a complex one as ps2
to manage more properly reloads) ?
You're not supposed to edit a generated file by your library to change the way it works while it's on. The library generates this file.
Let's back up. How are users of i18n-node-2
supposed to remove localizations from the file, other than editing the file? There is no "remove" or "delete" API. But it wouldn't even make sense to use such API since such API calls would be one-offs, removed immediately after they were executed.
Right?
Do you think this issue is somehow related to what you mean https://github.com/jeresig/i18n-node-2/issues/97 ?
Hm, maybe? I could describe what I'm looking for as syncing i18n-node-2's cache with the file. @kokujin, what do you think?
Repro steps:
Run this code:
Observe that the generated
en.js
file looks like this:en.js
before the 30 second timeout above elapses.After the timeout elapses, observe that the generated
en.js
file looks like this:Expected result:
i18n appears to keep a representation of the localization file in memory and flush that to disk with every call. Rather, it should treat the file as the single source of truth and just patch that with each call rather than entirely recreating it. By doing the latter, it overrides the developer's intent.