Open JaCoB1123 opened 9 months ago
Second this
I guess the assumption here is that you also have notes in german?
One thing I can think of is to have notes prefixed with locale, should work with redirect and crawlinks afaik.
Doable, lets see what @jackyzha0 thinks of this.
For me personally, an ideal implementation would be if you would define the language in the Frontmatter and have an option to define a fallback-language in case nothing is defined in the Frontmatter. That would interfere the least with existing note-taking-systems.
I agree with this proposal. It stands to benefit not only Quartz users worldwide but also the Quartz project itself. It would facilitate the localization of the documentation, currently available only in English, thereby broadening accessibility.
This feature sounds good, although it seems more logical to have the option to switch between languages with a toggle button, in which case the whole website switches and only includes the notes in the correct language. I don't see wikilinks between notes of different languages making a lot of sense.
Struggling with localization in a Quartz installation I'm testing and not being a developer but having tried to check the relevant parts of the code and issues/documentation, I was understanding or hoping that specifying a language code in ISO format in the YAML of a note with a "lang" key would not only make that the value of the lang
attribute in the <html>
tag (as it does), but it would also set that language as the one to use (if available in the localization files) for the texts of the interface when viewing that note in its published page as mentioned in this issue. So it doesn't seem to be the intended result. If it's not the intended result, could someone please explain how is it supposed to work, as I also don't see the interface language changing according to the browser language (which was the other possibility I was considering).
Sorry if this doesn't belong here. If that's the case, please direct me to an explanation elsewhere or what's the expected way to proceed.
Would love a feature like this, and to me it would make sense to have links between notes that are note of the same language if, for example, you haven't translated a note yet. So in this case it would fallback to the other language
I implemented this feature and need some users to test it on my site (https://notes.dynamotn.dev). I will put PR soon after verifying done all things.
I saw you have a multilang
transformers
https://github.com/dynamotn/quartz/blob/838796334a0ed729fc0e7167b97630986c2f31b8/quartz/plugins/transformers/multilang.ts#L4
fwiw I think it is better to parse notes based on folder directory instead of having multiple language within the same file.
@aarnphm I don't think so. If you organized your notes with multiple languages based on folder, eg. as a polyglot, you waste your time to compare all notes, translate it with correct location, refactor your notes with same format per each folder.
In same file with multiple language sections, user can handle and avoid these
Doesn't it also bring the issue that the title of the note is the same in both language ? Or could that be fixed ?
As for having language determined by folder, I think it could be helpful, since most text editor nowadays have the option of putting one file on the left and another on the right. But it is also possible with the same file so both option seem like they don't have this issue.
It could that be fixed Demo: https://notes.dynamotn.dev/en-US/07_Project-Notes/Do-I-have-to-introduce-myself-here
If you organized your notes with multiple languages based on folder, eg. as a polyglot, you waste your time to compare all notes, translate it with correct location, refactor your notes with same format per each folder.
But you will have to do this regardless of whether you put all your translations in one file or not, so I don't think this argument is that strong.
Separation of concern makes more sense. https://github.com/huggingface/transformers/tree/main/docs/source for documentations.
Given that you want to do multiple language, it is the user responsibility to maintain the translation up-to-date. Let's not reinvent new spec
Maybe my approach to handle this problem is not the same as @aarnphm or the above guys want to talk about. I have difficulty mentioning the same multilingual document with Graph view on Obsidian if divided into folders like that. If I use each note for each language, I will not have a comprehensive view to link each note, especially when I want to use it to check my translation ability into other languages only on Obsidian, then I will need other tools.
Btw I will still follow this issue, if anyone has the same idea to handle it like me, you can refer to it
Is your feature request related to a problem? Please describe. Now that #462 is fixed by #738 (thanks @Lisandra-dev), I'd like to request an extension to it: It would be nice to have the option to have multiple languages on the same site. This would mean, that I can have pages in different languages and Quartz' UI would update to match the current pages' language.
Describe the solution you'd like Ideally I would specify the language in each note. Quartz should then build the UI based on the current notes' language. It also should filter displayed notes by the current language (e.g. in Backlinks, search results, ...). It should be possible to have a language switcher somewhere, which switches to the current notes' matching language version. If that doesn't exist it could fallback to the home page.
Describe alternatives you've considered Coming from Hugo I got used to having a folder per language. The files could then be named identical in both folders and Hugo would pick them up as being the same page in different languages. I'm currently using Quartz in this way, and the language folders clutter up my
Additional context I'm unsure if it makes sense to set UI to EN and still open a note in another language (e.g. when switching from a German note with no English translation to English). Maybe showing a fallback as in "No translation for the current page is available" would make sense?