I18n for site and Front Matter configurations #125
Conversation
It was needed to remove duplicate code that resided in 'LocalizeTag.render' method and newly created 'SiteLocalize.translate_key'.
Correct handling of empty property name, a name defined as not a string and a name consists of only spaces has been added.
Also minor refactoring in favor of little optimization has been applied.
Class 'SiteLocalize' was renamed to 'Localizer' and reduced to a common implementation, not only for site configuration localization. A property which stores properties that must be localized renamed to 'localize_props'.
pgoltsev
changed the title
Method 'localize_to' of Localizer renamed to 'translate_to'. Name of a property for translation renamed from 'localize_props' to 'translate_to'.
A bug in 'serve' mode of Jekyll was fixed. The bug was in empty strings once site rebuilt because of an attempt to translate already translated strings once again. Class Localizer has been removed due to redundancy and has been replaced with function 'translate_props'. New class TranslatedString was instroduced to store a key within translated value and distinguish key and translated value.
|
Hi @pesh1983. The main administrator @Anthony-Gaudino, has disappeared so we are in a bit of a sad state here. I still have access to the Ruby Gem and can release new versions but I do not use any Jekyll sites and have no way of verifying PRs. In short this project really need a new owner, is that you? Or can you atleast verify all PRs so I can merge and make a release? |
|
Hi @kurtsson, |
That would be super helpful, thank you! |
|
Any update on the state of maintenance? I would be interested in helping out with PR's because I am using this gem myself and need new features/improved documentation anyways. |
Not really, I still own the gem but @Anthony-Gaudino is completely gone. I guess I could ask Github to transfer the project back to me but I'm not using the plugin myself so I rather not be the sole maintainer. But if someone is willing to pick it up, Im very grateful. Is that you @shushugah? Right now I'm approving PRs tested by the community and releasing new versions when asked for. |
|
I took the time to reflect on my time availability and technical expertise. I've never maintained an OS project before but would be very excited to take this challenge. I would ask for a transition/collaborative period, but am eager to take off some of the load from you. |
Cool! I also managed to get the ownership back of the project, so now I can add you as an admin for starters. |
|
Is this still valid? If not, I think I close it |
# Conflicts: # lib/jekyll-multiple-languages-plugin.rb
|
It is, I've updated the PR with the latest changes from the main branch. |
Is it verified? Should we release it? |
|
Yes, it is verified and can be merged. |
|
@pgoltsev Should I push this as 1.7.1 release or 1.8.0? |
|
@kurtsson I would release it under 1.8.0 because it is a new feature. Thank you |
|
In the new version 1.8.0 I get the error: "jekyll "Missing i18n key:" But the translation string exists in the .yml file. |
|
@team-community just the gem update and no other changes? |
Hello. All right. Only Gem has been updated. In my case, it's obviously related to |
|
I will check it soon. Thank you. |
Hi, @pgoltsev, I encountered the same issue. The Front Matter I am using is: ---
layout: newsv2
title: titles.news.all_news
permalink: /news/all_news/
pagination:
enabled: true
permalink: /:num/
sort_field: 'date'
sort_reverse: true
translate_props: ["title"]
---using Version 1.8.0, I got the following error: using Version 1.7.0, no error is reported, but the titles will not be translated. |
Rationale
I thought it would be very useful if site properties, which are defined in _config.yml->site map such as site.description, site.author, site.title etc. and some Front Matter's properties, may be transparently translated without explicitly using LocalizeTag. In many cases it could be very convenient and in some cases usage of the tag is just impossible. For example, transparent translation allows do not overwrite original theme files where site.title and similar are used just to be able to translate them. And it is impossible to apply translation tag on these properties in third-party plugins such as jekyll-feed. This plugin has 'feed.xml' template that could not be overrode in a simple way (and actually it isn't needed usually). Thus, transparent translation allows do not change any files at all because properties will be already translated when they will be put into templates.
Backward Compatibility
In order to preserve backward compatible behavior I introduced new property 'translate_props' that contains names of properties which must be transparently translated. In case if 'translate_props' is not defined no translation is performed which is default and the current behavior.
This implementation allows to define transparent translation in _config.yml as
And appropriate properties could be defined as paths to translation such as
Then every file _i18n/lang.yml must contain these paths
The same functionality was added for Front Matter of a page. Thus, in order to translate any property inside of Front Matter this property must be included into 'translate_props' of this Front Matter. For example, if we need to translate 'title' in About page, we can put these data into about.md
And add 'about.title' to every i18n/lang.yml
Extra Notes
I tested it against my current blog and it works fine. Likely, unit tests would be preferable against manual testing. But since I'm not good at Ruby at all (actually, I just met it first time when I wanted to make these changes) I have problems with creating them. I would be very thankful if you could either add them by yourself or share docs on me how to do it.
Although it is just a good implementation of Proof-Of-Concept it could be merged into upstream as is. But of course any improvements, including naming of variables, changes in architecture etc., are welcome.
Cheers!