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

[i18n_subsites] Move the default language output also in a subfolder (like a subsite) #182

Closed
Scheirle opened this issue Mar 27, 2014 · 11 comments
Assignees

Comments

@Scheirle
Copy link
Member

It would be nice to have an option to move the generated files for the default language also in a sub folder, and treat it like a subsite.

So instead of this: (tree view output folder)
├── author
├── de
│ ├── author
│ ├── feeds
│ ├── ....
├── feeds
├── ....

You would get this: (tree view output folder)
├── de
│ ├── author
│ ├── feeds
│ ├── ....
├── en
│ ├── author
│ ├── feeds
│ ├── ....

Assuming en is the default language and de a subsite.

With the patch below this is possible:
pelicanconf.py:

OUTPUT_PATH = 'output/en'
I18N_SUBSITES = {
'de': { 'OUTPUT_PATH' : 'output/de' }
}

Patch:

diff --git a/i18n_subsites/i18n_subsites.py b/i18n_subsites/i18n_subsites.py
index 2ae30e7..5bcdea0 100644
--- a/i18n_subsites/i18n_subsites.py
+++ b/i18n_subsites/i18n_subsites.py
@@ -67,7 +67,8 @@ def create_lang_subsites(pelican_obj):
         settings = orig_settings.copy()
         settings.update(overrides)
         settings['SITEURL'] = _lang_siteurls[lang]
-        settings['OUTPUT_PATH'] = os.path.join(orig_settings['OUTPUT_PATH'], lang, '')
+        if (not overrides.has_key('OUTPUT_PATH')):
+            settings['OUTPUT_PATH'] = os.path.join(orig_settings['OUTPUT_PATH'], lang, '')
         settings['DEFAULT_LANG'] = lang   # to change what is perceived as translations
         settings['DELETE_OUTPUT_DIRECTORY'] = False  # prevent deletion of previous runs
         settings = configure_settings(settings)      # to set LOCALE, etc.

Note: If you are using the makefile to build your site, you have to remove the -o option.

@smartass101
Copy link
Contributor

Thank you for your fix, will commit it later and will use this approach also for other settings.

@Scheirle
Copy link
Member Author

Hm, this fix breaks the feeds. They still point to the old url.

You get: example.com/posts/article.html instead of example.com/en/posts/article.html

@Scheirle
Copy link
Member Author

Nope. I did the thing for the SITEURL. The problem is if HIDE_UNTRANSLATED_CONTENT is False and you are currently generating the english site (therefore SITEURL= 'example.com/en/), the german articles generate this url example.com/en/de/posts/....
While generating a subsite the english articles generate example.com/de/../posts/....

@smartass101
Copy link
Contributor

I think the culprit here is the move_translations_links function. It needs to do something more sophisticated when you arbitrarily change the settings as it expects the layout I used. Perhaps urllib.parse would have to be used to unparse the source and target destinations and modify them accordingly. I think I did try something like that in the beginning but gave up, because using the simple default layout seemed much simpler and less error prone. I think the difference between absolute URLs and relative ones was the main problem.

Maybe you'll be more lucky :) I'm looking forward to your implementation of the function. I might have a look at it later.

@smartass101
Copy link
Contributor

Here is a rough idea of the redesign of the plugin, needs the get_writer signal from getpelican/pelican#1330 though.

Process:

  1. Let pelican run up to get_writer signal, then run pelican for next subsite, in each run save each generator in some global dict and remove translations (in pretaxonomy if available) but save the relationships to translations (Content.source_path being the "primary key" in this relational db)
  2. recurse until last language subsite, then assign for each content assign to content.translations the translated content from the generators in the subsites where the translations are not perceived as translations (i.e. not removed from the main content list)
  3. then finally write everything

@smartass101
Copy link
Contributor

I've made a first concept, but the problem is that all URLs used internally by Pelican are always relative to the current SITEURL, so specifying arbitrary SITEURL would require very ugly hacks within Pelican an templates.

Therefore, I propose that this plugin would enable to specify arbitrary SITEURL overides that would get appended to the main site SITEURL, enabling a custom hierarchy using ../. E.g. the layout decribed above could be achived using something like

SITEURL = 'http://example.com/en'
I18N_SUBSITES = {
'de': { 'SITEURL' : '../de' }
}

OUTPUT_PATH could be theoretically completely arbitrary, but by default it would also just get the SITEURL override appended.

If this design is accepted, the site and subsites would have some hierarchal structure and #180 could be implemented using ../ pointers.

@Scheirle, what do you think?

@Scheirle
Copy link
Member Author

@smartass101 I think appending the SITEURL is fine but maybe it will confuse some new users.

Also the plugin should simplify the SITEURL after the concatenation (http://example.com/en/../de becomes http://example.com/de/) so that not every URL on a subsite looks strange.

@smartass101
Copy link
Contributor

@Scheirle, I agree that appending SITEURL is a bit confusing, but do you know of some simpler way to enforce some processable hierarchy within the different SITEURLs? What I would be ok with would be if there would be some simple way to parse the different SITEURLs and determine their hierarchy and warn if the hierarchy is inconsistent.

Simplifying them after concatenation should be easy thanks to posix.normpath when applied to the path part of the URL.

@smartass101
Copy link
Contributor

@ingwinlu was so kind and provided a nice way to find the distance of the paths in https://gist.github.com/ingwinlu/20615105bba903ccf0d8, will see if I can use that.

@smartass101
Copy link
Contributor

@saimn was so kind and also provided a solution in https://dpaste.de/7CY4

@smartass101
Copy link
Contributor

@spiroid, please don't ask for support in issues that may not have anything to do with your problem. I suggest you come to the #pelican IRC channel and ask for help there. And the description you provided is so vague that nobody can help you, so be prepared to give a concrete example on IRC.

smartass101 added a commit to smartass101/pelican-plugins that referenced this issue Nov 2, 2014
Major highlights
................
- fixed and improved cross-linking (fixes getpelican#333) with URLs
  containing e.g. localized month names
  (thanks to issue getpelican/pelican#1198)
- support for custom ``SITEURL`` and ``OUTPUT_PATH`` hierarchy
  (fixes getpelican#182)
- sharing of static files (including those of the theme) among
  subsites (fixes getpelican#180)

Technical highlights
....................
- added a test suite (works with pelican 3.4)
- translations are installed into Jinja2 environments of all
  generators
- old locale is restored after generation, fixes autoreload

The documentation has been updated and improved (mostly in terms of
formatting).

Known issues
............
- due to the redesign required for correct cross-linking, older
  versions of Pelican (<3.4) are not supported, because they lack
  certain signals
- the ``HIDE_UNTRANSLATED_CONTENT`` setting has been deprecated in
  favor of the ``I18N_UNTRANSLATED_{ARTICLES,PAGES}`` settings which
  offer more control in order to fix getpelican#211.
- the test suite works only with pelican 3.4, later versions add a
  timezone field to the date
calfzhou pushed a commit to calfzhou/pelican-plugins that referenced this issue Sep 28, 2019
* Change license text to be SPDX and REUSE conformant

ref:

- <https://reuse.software/practices/2.0/>
- <https://spdx.org/>

* Fixed link to Google HTML/CSS style guide

* New intro, reorganise screenshots

* Add Kate swap file to gitignore

* Clarify documentation status

* Updated basic contribution policy

- to match the license
- to match the new repositories
- some basic rewording to make it clearer

* Fix missing parts of licensing sentence

* Removed Talha Mansoor’s name from the footer

as agreed by Talha Mansoor in <Pelican-Elegant/elegant#175>
and <Pelican-Elegant/elegant#173 (comment)>

* Add AUTHORS

* Fix typo in AUTHORS

* Fix tiny typo
rschiang pushed a commit to rschiang/pelican-i18n-subsites that referenced this issue Aug 9, 2022
Major highlights
................
- fixed and improved cross-linking (fixes getpelican/pelican-plugins#333) with URLs
  containing e.g. localized month names
  (thanks to issue getpelican/pelicangetpelican/pelican-plugins#1198)
- support for custom ``SITEURL`` and ``OUTPUT_PATH`` hierarchy
  (fixes getpelican/pelican-plugins#182)
- sharing of static files (including those of the theme) among
  subsites (fixes getpelican/pelican-plugins#180)

Technical highlights
....................
- added a test suite (works with pelican 3.4)
- translations are installed into Jinja2 environments of all
  generators
- old locale is restored after generation, fixes autoreload

The documentation has been updated and improved (mostly in terms of
formatting).

Known issues
............
- due to the redesign required for correct cross-linking, older
  versions of Pelican (<3.4) are not supported, because they lack
  certain signals
- the ``HIDE_UNTRANSLATED_CONTENT`` setting has been deprecated in
  favor of the ``I18N_UNTRANSLATED_{ARTICLES,PAGES}`` settings which
  offer more control in order to fix getpelican/pelican-plugins#211.
- the test suite works only with pelican 3.4, later versions add a
  timezone field to the date
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants