Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

💻 Proposal for navigating through subdomains, and communities #5814

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

jpelay
Copy link
Member

@jpelay jpelay commented Sep 26, 2024

This PR is a proposal showing how the inclussion of these features would look like and the work required to make them work.

Navigation through Subdomains

#5720 suggests an idea for us to be able to navigate through different languages by prefixing the domain with the language code, the example offered there is cn.hedy.org. This is indeed possible as seen in the changes made in app.py inside this PR, but it poses some problems:

  • All functions need to be modified. This means that every existing route needs to include the subdomain parameter, otherwise they won't work.

  • In order for routes without the subdomain prefixed to work, I think we need to add functions for every route to redirect. This happens because after adding the subdomain parameter, if you do put it in the URL Flask will tell you that the URL doesn't exist, like I did in the function index_test before adding it, I wasnt able to enter that route.

  • We don't have a code for cn, the codes we use for Chinese are zh_Hans and zh_Hant, which don't make up for pretty domain names. Shall we mantain manual subdomains for cases like this, I would assume that cn would redirect to zh_H

Communities

For communities I created a folder inside templates, in this folder would be other subfolders for every community. In this case there would be a mandatory index.html file that serves as the home for the community, and then we can add any number of additional HTML files. All of these files would appear in the left hand side in a side pane.

@jpelay
Copy link
Member Author

jpelay commented Oct 1, 2024

We concluded in the meeting that we'd be moving forward with language codes as subdomains, keeping them the same, for example: es.hedy.org, en.hedy.org, zh_hans.hedy.org

Regarding the community, we decided that they won't be tied to a subdomain, rather getting a route, in this case the chinese community would be:

zh_hans.hedy.org/cn/community

This would allow us to have various communities in a single language, for example in Spanish:

es.hedy.org/ve/community (for Venezuela)
es.hedy.org/col/community (for Colombia)

I'll be leaving this PR as is for now, so we can get @ZoomQuiet feedback on the matter.

@jpelay jpelay marked this pull request as draft October 3, 2024 15:54
@ZoomQuiet
Copy link
Contributor

Thanks for your comprehensive thinking. I feel that this method can further support more communities, such as:

  • cn.hedy.org/tw/community (for TaiWan)

  • cn.hedy.org/hk/community (for HongKong)

  • ...

However, how should this mechanism be used specifically?

By submitting PR in the agreed directory?

However, how to reuse the style of the corresponding official webpage?

For example:

We want to create a webpage to comprehensively explain the progress of various affairs of the Chinese community.

We hope to use the style of the following webpage:

https://hedy.org/for-teachers/manual

How to build it based on Markdown?

We use tools such as MkDocs, but,

That kind of SSG tool is used to generate the entire website, and the available styles are very limited:

Choosing Your Theme - MkDocs

And customization is not easy;

If the Chinese community is allowed to use different styles, That's good, but it looks strange;

In short:

  • 1: zh_hans.hedy.org is too complicated, why not support cn.hedy.org? And, the proposal is to support local communities in various countries, not language versions;
  • 1.1: If the system is really inconvenient to automatically redirect the domain name to cn.hedy.org, then, should a 301 redirect be configured? Automatically jump to zh_hans.hedy.org when visiting cn.hedy.org, so as to promote and remember cn.hedy.org instead of the complicated version?

It is found that it is an HTML page containing template instructions:

{% extends "communities/community-template.html" %}
{% block community_content %}
...

That is to say, this is the front-end template of the hedy system,
We use markdown to convert the HTML code,
If you don't modify these template lines, you can naturally use the official website style?

@jpelay
Copy link
Member Author

jpelay commented Oct 8, 2024

However, how should this mechanism be used specifically?
By submitting PR in the agreed directory?

Yes the idea is that by submitting a PR to this repository we can check your changes to it, and the changes made should happen within the folder of your community.

However, how to reuse the style of the corresponding official webpage?

Since the files you are going to submit are part of our website, it will inherit the styles of our page. So you can just write normal articles using h2, h3, p, etc. And we are also going to take a peek on the uploaded files, to see that everything looks fine.

How to build it based on Markdown?

If you see the code I uploaded to this PR, you can see that it contains the same articles you uploaded to your site. So, basically, you could just use a Markdown to HTML converter, and paste that code to the Hedy repository, upload that and you should be good to go.

1: zh_hans.hedy.org is too complicated, why not support cn.hedy.org? And, the proposal is to support local communities in various countries, not language versions;

Because cn is not a language code, the subdomains are meant to set the languages of the page.

2: How can we reasonably use the same style as the official website? If we can customize a hedy official style based on MkDocs, and everyone can use it, this idea may be more usable? Can we start this auxiliary project to try it?

Just paste plain HTML to a file within the community/cn folder.

We use markdown to convert the HTML code,
If you don't modify these template lines, you can naturally use the official website style?

Yes exactly! 😄

@Felienne
Copy link
Member

Felienne commented Oct 8, 2024

Because cn is not a language code, the subdomains are meant to set the languages of the page.

I also find the language code annoying, I really get it but following international standards makes other things a lot easier.

And to elaboratie a bit more, not all language communities are also singular countries and vice versa. Dutch (nl) for example is spoken in the Netherlands and also Belgium, they want to share the same Hedy version in terms of content but might have different communities.

This way, we can create nl.hedy.org/nl for Dutch in the Netherlands and nl.hedy.org/be for Dutch in Belgium (and potentially also fr.hedy.org/be for the Wallons). In your case it might be a bit annoying, yes, but please remember we want to create a solution that solves this problem at once for many situations.

If we create the system of country.hedy.org now for communities (as you suggest) you see how we can no longer maintain our different communities.

In the system we envision now, you can also use www.hedy.org/cn but then the site would be in English, which I guess is not what you want (but is a nicer url).

@ZoomQuiet
Copy link
Contributor

Because cn is not a language code, the subdomains are meant to set the languages of the page.

I also find the language code annoying, I really get it but following international standards makes other things a lot easier.

Maybe we have all forgotten the original purpose.
It is not to create a new entrance for different language versions of the hedy official website;
but:

  • Use hedy.org as the root domain name
  • Support local communities in different countries through cn.hedy.org
  • Even some theme activities, such as:
  • con.hedy.org/cn2025 ~ Hedy2025 China Conference
  • code.hedy.org ~ Online Programming Competition
  • ...

In other words, the official domain name is a series of powerful, natural, easy to remember, and naturally associated with the brand resources;

  • zh_hans.hedy.org is a technical resource, not a community communication resource
  • Moreover, this form is equivalent to not recognizing one China, and splitting China cn into simplified and traditional parts using the technical attributes of UTF-8
  • Furthermore, due to historical reasons, there are many language tags involving Chinese: zh-cn, zh-Hans, zh-SG, zh-HK, zh-MO, zh-TW ...
  • If you divide subsites automatically by language tags, you will find that although there are different domain names, the specific characters are only divided into simplified and traditional

In summary, it is still recommended to use the country code as the host name. If there are different language versions, you can further specify them by directory division, for example:

  • cn.hedy.org/tibt/ Tibetan version
  • cn.hedy.org/kr/ Korean version, because there are Koreans in China
  • ...

@Felienne
Copy link
Member

Felienne commented Oct 9, 2024

I really see that the language codes are not nice, but we need a way to tell Hedy what language to serve (we now do this with ?lang=zh_Hans which is as annoying). So somewhere, we need to somehow encode in the URL what the language is to serve the right one. It can be before or after Hedy, but it needs to go somewhere (ch.hedy.org/zh_Hans or zh_Hans.hedy.org/cn)

I think it would be good to recognise that we have different goals here:

  • Our goal is to come up with a simple system that works well for many languages and situations
  • Your goal is to have a nice url and a simple system to work with

As with large projects involving many people, we have to try to find a middle ground.

Jesus already propsed redirecting www.hedy.org/cn to zh_Hans.hedy.org/cn, would that be an acceptable middle ground?

@ZoomQuiet
Copy link
Contributor

ZoomQuiet commented Oct 9, 2024

  • Our goal is to come up with a simple system that works well for many languages and situations
  • Your goal is to have a nice url and a simple system to work with

As with large projects involving many people, we have to try to find a middle ground.

Jesus already proposed redirecting www.hedy.org/cn to zh_Hans.hedy.org/cn, would that be an acceptable middle ground?

I understand a little bit, where is the deviation of the goal discussed before...

In fact, originally at: https://hedy.org/my-profile
Through personal configuration, specifying the display language, it has already completed:

A simple system that supports all languages

This official goal;

And the goal that our Chinese community expects has nothing to do with the different language display of the current hedy official content;

  • Expect to use the cn.hedy.org domain name to publish community content

  • If it is not convenient to automatically forward our published website through technical solutions such as reverse proxy

  • Then, providing an agreed channel to publish relevant content to the directory agreed on the official website is also OK

That is to say:

  • The content published by cn.hedy.org has no direct content connection with the original content of hedy

  • It is a simple official sub-community, which is naturally certified by the domain name

  • Used to publish content for local publicity/learning/promotion/operation/...

In short, expect a community publishing space that can be maintained independently;

Accept the official content review/publishing process;

@Felienne
Copy link
Member

Felienne commented Oct 9, 2024

In fact, originally at: https://hedy.org/my-profile
Through personal configuration, specifying the display language, it has already completed:

Yes this is true but then you have an account and it is stored in the database. But I assume that you also want to have people without an account view the site in Chinese, which is why we need a language setting somewhere.

We can move forward with the plan as explained above, and we can redirect cn.hedy.org to our internal url, than I think we all have a very workable solution.

So in short:

  • cn.hedy.org will work, it will redirect to a less nice but easier to maintain url. This is an internal forward, not a reverse proxy!
  • You can submit content with a PR as described

I propose we move this forward, and then see how well it works for everyone. We can always make changes later.

@ZoomQuiet
Copy link
Contributor

So in short:

  • cn.hedy.org will work, it will redirect to a less nice but easier to maintain url. This is an internal forward, not a reverse proxy!
  • You can submit content with a PR as described

Agreed:

  • We can promote cn.hedy.org
  • Submit content every week through the agreed directory and publish it to cn.hedy.org

This is very feasible and usable,
Let's get started ;-)

@ZoomQuiet
Copy link
Contributor

ZoomQuiet commented Oct 21, 2024

@jpelay @Felienne
The final available solution has been decided:

  • templates/communities/zh_hans/ is the agreed directory
  • The Chinese community will submit the appropriate html files to this directory through PR
  • When the website is updated every week, it will be automatically published to zh_hans.hedy.org
  • In order to facilitate publicity and memory, a special automatic jump rule will be configured from cn.hedy.org -> zh_hans.hedu.org

However, I have not seen the main branch contain this directory so far.
When can the above community content publishing process be carried out?

@Felienne
Copy link
Member

@jpelay @Felienne The final available solution has been decided:

  • templates/communities/zh_hans/ is the agreed directory
  • The Chinese community will submit the appropriate html files to this directory through PR
  • When the website is updated every week, it will be automatically published to zh_hans.hedy.org
  • In order to facilitate publicity and memory, a special automatic jump rule will be configured from zh.hedy.org -> zh_hans.hedu.org

However, I have not seen the main branch contain this directory so far. When can the above community content publishing process be carried out?

Hi @ZoomQuiet!

Indeed these changes are not yet in main, that will happen when we finish and merge this PR. @jpelay can surely give you an estimate on when this will be ready, but because it is a bog complex change, it might take a little while.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: ToBeDiscussed
Development

Successfully merging this pull request may close these issues.

3 participants