twinejs
twinejs copied to clipboard
Web-browser based release shows translate keys instead of locale values
Describe the bug.
As reported on intfiction forum by Mercutio Escalus, and tested by myself on a English locale Windows 10 based PC using Chrome and Firefox .
The 2.5.1 (and possibly earlier) version of the Web-browser based release no longer replaces the translation keys with their locale specific values when the index.html file is opened within a web-browser after the contents of the downloaded ZIP file have been extracted to a local hard-drive.
Currently anyone that wants to use the web-browser based release locally needs to access the index.html file through a locally installed web-service, which is a less than ideal requirement. It was previously possible to run the Web-browser based release locally without the need for a web-server.
Steps to reproduce:
- Download the twine-2.5.1-web.zip archive file from the Releases page of this repository.
- Extract the contents of the archive file onto a local hard-drive.
- Open the index.html file that was extracted within a supported web-browser like Chrome or Firefox.
Expected behavior:
The translation keys should be replaced with a locale specific value, or with the English locale value if end-user's locale is not supported.
Additional context on this problem.
No response
Twine version number
2.5.1
Does this problem occur with the web version of Twine or the desktop app?
Web
What operating system does this problem occur on?
Windows
If this problem is occurring with the web version of Twine, what browser does it occur on?
Chrome/Chromium
Presubmission checklist
- [ ] I am interested in working on code that would fix this bug. (This is not required to submit a bug report.)
- [X] I have done a search and believe that an issue does not already exist for this bug in the GitHub repository.
- [X] I have read and agree to abide by this project's Code of Conduct.
The cause of this is that Twine 2.4+ uses i18next instead of a bespoke locale loading system. The old system loaded locale strings using specially-generated JS files which skipped browser security restrictions, and were less secure as a result. The current system loads JSON files which can't contain executable code.
I'd be open to a PR to address this, but it would need to meet a couple criteria:
- Continues to use i18next
- Does not require bespoke generation of translation files
- Does not bundle all locales into the build (this is for performance reasons)
This is hugely disappointing!:( It would be great to have that fixed, or at least some workaround! I need to use Twine web version locally, because the online one has issues with locally stored images, and the desktop one doesn't have a proper search feature.
The workaround is to serve this version using a local web server. There are many options available to do this, so I can't recommend any one in particular.
Same here, long story short: i need to use the web version locally, would love to see that bug fixed.
The workaround is to serve this version using a local web server. There are many options available to do this, so I can't recommend any one in particular.
Is there any web server that would also allow me to easily load local media files?
@JohnProblem
Is there any web server that would also allow me to easily load local media files?
What Operating System (brand & version) are you running? And if a version of Windows, have you installed any scripting languages (like Python) on that machine?
Windows 11, no scripting languages, just Twine with SugarCube2;)
Recent versions of Windows come with a pre-installed scripting language named PowerShell, which can be used run commands made available by the Modules that are installed.
There are modules that you can install which add new commands that can be used to allow accessing HTML files stored in a folder on your machine in a way that behaves like a limited featured web-server.
However I personally have not used any of those PowerShell modules, and the process of installing & configuring any of them that decide to use may not be a simple as one could hope, as in some cases you will need to understand setting installation and execution Policies for your Windows setup.
I personally use the http.server module that comes built-in with the Python 3 scripting language, which can be downloaded and installed on Windows,
Once installed correctly serving HTML files from a specific folder on your hard-drive is as simple as:
a. Open File Explorer and navigate to the folder in which the HTML file(s) resides.
b. Use File Explorer's File > Open Windows PowerShell > Open Windows PowerShell menu items to open a PowerShell command window that targets the current folder.
c. Type python -m http.server at the command prompt then press the Enter key on your keyboard to execute that command, this will start the mini web-server.
d. Open your favourite Web-browser and type http://localhost:8000/ into its location bar. This should result in a list of the files contained within the current folder being shown.
e. Select the HTML file you want to access from that list.
When you want to stop the mini web-server simply close down the PowerShell command window.
Hey @greyelf, thanks for this. I'll take a look and pick something up. I hope to avoid installing new background applications, because from my experience those type of apps are often resource heavy. So Powershell looks better for me, as it's already there. I'll let you know if it worked.
@JohnProblem
I hope to avoid installing new background applications, because from my experience those type of apps are often resource heavy.
Python itself doesn't run any background services unless you tell it to.
The Python http.server module I mentioned doesn't run as a background service, it is just module "code" that Python runs interactively when you execute the command I supplied, and that "code" stops running when you close that PowerShell window. So the only time you need to worry about any resources that module may consume is while it is running within the open PowerShell window.
This is one reason I use that module, because it isn't a background service like many other local web-servers are.