The protocol says that servers can emit lang paramenters but it's difficult for the server to figure out the value of that parameter since it's not in the gmi files. Have others figured out a best practice for this?
Sandra Snan <sandra.snan at idiomdrottning.org> wrote: > The protocol says that servers can emit lang paramenters but it's > difficult for the server to figure out the value of that parameter since > it's not in the gmi files. Have others figured out a best practice for > this? > It's up to the server author on how to do it. The best thing would be to standardize the procedure so it's easy to migrate between servers, but that has not been done yet. >From what I've seen through my limited experience is using some meta data file for files deviating from the default language. -- Katarina > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200830/9dc0 d68c/attachment.htm>
Hi Sandra, On Sun, 30 Aug 2020 18:15:35 +0200 Sandra Snan <sandra.snan at idiomdrottning.org> wrote: > The protocol says that servers can emit lang paramenters but it's > difficult for the server to figure out the value of that parameter since > it's not in the gmi files. Have others figured out a best practice for > this? You can use a sidecar file, like .htaccess for web servers. For example, if you have cheval.gmi (in french) and horse.gmi (in english) you could have a file beside them that lists the language parameter for each file. $ cat .language horse.gmi: fr cheval.gmi: en Another approach is to have language extensions in the filename, for example horse.gmi.en and cheval.gmi.fr and let the server interpret the extensions to decide on the language parameter. I think web servers like Apache 2 support both of these methods in some form, so taking a look at how Apache 2 does it might be useful. -- Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200830/0c88 c53f/attachment.sig>
It was thus said that the Great Sandra Snan once stated: > The protocol says that servers can emit lang paramenters but it's > difficult for the server to figure out the value of that parameter since > it's not in the gmi files. Have others figured out a best practice for > this? With GLV-1.12556, you can specify the MIME type of a file via it's extension. This will override the normal method of detecting the MIME type by looking at the contents. As a side-effect, you can also specify the language parameter. GLV-1.12556 doesn't do this (yet) but another option is to have the server lookg for a configuration option to always set the languate parameter to a known value. -spc
Right, thank you all for your answers so far!? I guess what I should've asked is to what extent servers already can do this. Sean mentioned GLV-1.12556 but it's not in sample-conf.lua as far as I can see. I guess with gig writing a custom router is also an option. I just don't wanna be reinventing any existing wheels. I have a collection of texts in a mix of languages. Each file is written in a single language. I'm OK with a sidecar per file, a sidecar per directory, one big sidecar for the entire site, or with renaming the files: for example the server gets the request for foo.gmi, it finds foo.en.gmi and serves that up as foo.gmi in English. (Or a similar convention, foo.gmi-en, foo-en.gmi, foo.en, I can adapt my data to fit what the server wants.) For the sidecar solutions, I obv don't want to serve up those sidecars via Gemini requests, they're for the server's eyes only. Any server so far do any one of those four things (with an already existing module, plugin, configuration, or out of the box)? I understand that Gig or GLV-1.12556 can do it with scripting; does those scripts already exist? This isn't a showstopper for me getting on Gemini, I'm plowing ahead and just not putting any language parameters in, but, I'm almost done with the "generating the site" part and am about to choose a server implementation. If it doesn't exist I'll put adding the language tags very far down on the "someday/maybe" list. So exhausted RN...?
It was thus said that the Great Sandra Snan once stated:
> Right, thank you all for your answers so far!?
>
> I guess what I should've asked is to what extent servers already can do
> this. Sean mentioned GLV-1.12556 but it's not in sample-conf.lua as far
> as I can see. I guess with gig writing a custom router is also an
> option.
Ah, I see I failed to give some good examples of this in sample-conf.lua.
You can certainly do this in GLV-1.12556 on a server-wide, host-wide, or
directory-wise or file-wise manner. For example, if you have Swedish
material in a given directory, you can do:
hosts =
{
['example.com'] =
{
handlers =
{
{
path = "^(/Swedish-stuff/)(.*)",
module = "GLV-1.handlers.filesystem",
directory = "/path/to/contents",
index = "index.gmi", -- GLV-1.12556 defaults to .gemini
extension = ".gmi",
mime =
{
gmi = "text/gemini; lang=se_NO", -- <<<< important bit
txt = "text/plain; lang=se_NO",
}
}
}
}
}
If you don't include the mime section, the server will (at least on Linux,
or any POSIX system with GNU's libmagic installed) return whatever it deems
is the MIME type for a given file (it uses magic values and huristics to
determine the MIME type).
The sample-conf.lua file has several mime blocks scattered throughout to
show where it can be included.
> I just don't wanna be reinventing any existing wheels.
>
> I have a collection of texts in a mix of languages. Each file is written
> in a single language.
>
> I'm OK with a sidecar per file, a sidecar per directory, one big sidecar
> for the entire site, or with renaming the files: for example the server
> gets the request for foo.gmi, it finds foo.en.gmi and serves that up as
> foo.gmi in English. (Or a similar convention, foo.gmi-en, foo-en.gmi,
> foo.en, I can adapt my data to fit what the server wants.) For the
> sidecar solutions, I obv don't want to serve up those sidecars via
> Gemini requests, they're for the server's eyes only.
Hmmm ... good point.
> Any server so far do any one of those four things (with an already
> existing module, plugin, configuration, or out of the box)?
>
> I understand that Gig or GLV-1.12556 can do it with scripting; does
> those scripts already exist?
While the configuration file for GLV-1.12556 is a Lua script, you can
think of it more as a configuration file. So in this case, GLV-1.12556 can
be configured to do this out of the box.
On the downside, installing GLV-1.12556 might not be that easy, as it
relies upon LibreSSL instead of OpenSSL. And GNU libmagic, which somes
stock on Linux, not sure about other systems.
-spc
Thank you for the follow up, Sean! Sean Conner <sean at conman.org> writes: > While the configuration file for GLV-1.12556 is a Lua script, you can > think of it more as a configuration file. So in this case, GLV-1.12556 can > be configured to do this out of the box. I don't mind writing some Lua, Go, CL or any other language but that kinda fiddling will have to go on the back burner for now.
On Mon Aug 31, 2020 at 6:08 AM CEST, Sandra Snan wrote: > I'm OK with a sidecar per file, a sidecar per directory, one big sidecar > for the entire site, or with renaming the files: for example the server > gets the request for foo.gmi, it finds foo.en.gmi and serves that up as > foo.gmi in English. (Or a similar convention, foo.gmi-en, foo-en.gmi, > foo.en, I can adapt my data to fit what the server wants.) For the > sidecar solutions, I obv don't want to serve up those sidecars via > Gemini requests, they're for the server's eyes only. > > Any server so far do any one of those four things (with an already > existing module, plugin, configuration, or out of the box)? Molly Brown will read settings from files named .molly, which are analogous to Apache's .htaccess files. One of the settings which are valid in these files is `DefaultLang`. The provided value will be applied to any .gmi file in the same directory as the .molly file, or any subdirectory of that directory - though another .molly file deeper down the path might override this. This works out of the box, all you need to do is set `ReadMollyFiles` to True in the main config file to enable it. Cheers, Solderpunk
It was thus said that the Great Sandra Snan once stated: > Thank you for the follow up, Sean! > > Sean Conner <sean at conman.org> writes: > > While the configuration file for GLV-1.12556 is a Lua script, you can > > think of it more as a configuration file. So in this case, GLV-1.12556 can > > be configured to do this out of the box. > > I don't mind writing some Lua, Go, CL or any other language but that > kinda fiddling will have to go on the back burner for now. What kind of fiddling? It's pretty much just configuration. -spc
This is what I just implemented using Molly. I had to put every gmi file in its own directory :( Not really what I wanted but at least now files have the right lang. That's important to people using screen readers. Gemfeed doesn't work with this solution but I figured out a workaround.
Sean Conner <sean at conman.org> writes: > It was thus said that the Great Sandra Snan once stated: >> Thank you for the follow up, Sean! >> >> Sean Conner <sean at conman.org> writes: >> > While the configuration file for GLV-1.12556 is a Lua script, you can >> > think of it more as a configuration file. So in this case, GLV-1.12556 can >> > be configured to do this out of the box. >> >> I don't mind writing some Lua, Go, CL or any other language but that >> kinda fiddling will have to go on the back burner for now. > > What kind of fiddling? It's pretty much just configuration. Fiddling such as writing handlers. I was absolutely exhausted last weekend and wanted my gem site up quickly.
---
Previous Thread: Geminaut, anyone else have Antivirus rejecting the executable?