search

goldsky / Lingua

MODX's Lexicon switcher for front-end interface
18 stars 11 forks source link

Need a Published checkbox / setting for Languages #29

Open valZho opened 9 years ago

valZho commented 9 years ago

Currently there are 2 states that a language can be in: Active or Inactive. Practically speaking, there should be 3 states: Inactive, Active, and Published.

Translation and/or loading up of translations is not an instantaneous process. There should be a mechanism by which material can be worked on without it showing up on the front end incomplete.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/6890845-need-a-published-checkbox-setting-for-languages?utm_campaign=plugin&utm_content=tracker%2F1919378&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1919378&utm_medium=issues&utm_source=github).
4ntz commented 9 years ago

What about resources that I do not want to show up in a specific language at all? For example: I have a site that contains 10 resources. I want to show all 10 resources in language #1 (de) but only 7 of them in language #2 (en) because 3 resources are not relevant to language #2 and will not be translated.

valZho commented 9 years ago

That's a good point... perhaps the "Publish" check-box should be language-specific along with the content, title, etc. when editing a resource. Seems like that would take care of everything.

Actually, I would still like to have a publish/active/inactive status per language. That way you can work on adding translations to pages—marking the new translation as published as each page is finished—and then when some critical mass is reached on the amount of entered content you go "publish" the language in the language menu to turn on the output of that language. Without that, you could have 50, 100, or more pages that you would have to then go back into and individually mark as published. Better to have both mechanisms in place.

4ntz commented 9 years ago

I think it's a great idea to make the "Publish" checkbox language-specific, that would be a good start. Is there already a workaround to make this happen? Or would that be easy to implement?

valZho commented 9 years ago

I was thinking about this some more this morning. It occurred to me that to have a page "unpublished" in a particular language would mean you would have to pick between one of two behaviors:

  1. The page doesn't show up at all if that language is selected in the front end... the entire page is truly "unpublished" if you have that language selected.
  2. The page reverts to the default language when it is called on by the front end... the translated content for that page is what's unpublished. (If you unpublish the default language, then the entire page would then be published).

I have a strong preference for things to behave as in number 2 rather than number 1 and think number 2 should be the default (although maybe it could eventually be a preference?). Number 2 should be very easy to implement based on how things are set up now: the default language is just the plain MODX resource table, with a special Lingua resource table containing translations that can override the data being delivered to the front end.

I would think that number 1 would be much much harder to implement in a consistent way as it would affect so many different things--menu generation (Wayfinder, etc), link tags, and so on. I think this is why the author stated (somewhere... forums maybe?) that if you want different languages to have different site structure, you are probably better off sticking with Babel's multi-context solution.

Having said all that, it probably would be far less confusing / better UX to add a checkbox to each translated page to indicate whether a translation is "Active" or not at the page level rather than putting the flag next to the "Publish" check box since the behavior of the Publish check box would be different for translations (revert to default) compared to the default language (unpublish page).

4ntz commented 9 years ago

But is your preferred method #2 not what is actually going on at the moment? If you do not translate a resource and switch language then you still see the original's language. I think a better improvement would indeed be #1. Why? Because when I do not want a page to show up in a specific language, then I don't want it to show up AT ALL. Not in Wayfinder Menus, not in getResources calls etc.. it should not EXIST in that other language. Imagine this: You have a website which contains a blog. I come from Germany, so my default language is German. I want to translate my site into English but not my blog - because it is not relevant to people which are not in Germany or don't speak German. Doesn't matter.. I just don't want / need it. So the links to my blog should not appear in my menu (or anywhere else on my site) when I switch language to English. Just like if it was REALLY unpublished for the english version of my site. If you switch to English and STILL see the german blog.. that is not what i want. That is not the english version of my website, its mixed up.

I have read goldskys comment about Babel, too. But honestly: I don't want to go back to Babel any more after using Lingua. And that would be the only difference that is left - to be able to pubslih / unpublish sites according to my (language-)specific needs. The whole page. Not only the translation. So I vote for #1 ;-)

valZho commented 9 years ago

I can see the need for both, I suppose.

2 is not what's going on now, though. You can't enter anything at all into a translation until you are ready for it to show up, i.e., you can't have any translations in-progress but not ready for display to the user. As soon as you enter anything--even just the pagetitle--you are going to get the translated content. Hence the whole purpose behind this post... the need for setting a third state at the page and language level: in-progress (save the data, but don't show it to the user).

I think eventually having an "active/inactive" option for each translation (except for the default language) (#2) in addition to having the Publish check box be language-specific (#1) would be the ideal end goal. I just think that #2 would be FAR easier to implement and could roll in pretty quickly, and #1 is probably going to take a lot more effort and planning.

Also... I agree, I think Lingua is a much nicer solution than Babel... especially for us as we are managing multiple sites through contexts... which makes me realize that I need to submit another feature request regarding contexts!

4ntz commented 9 years ago

@valZho now I understand what you mean. And yes, I think that would be a great end goal to get both things implemented. I also see the need for working on translations while not displaying them automatically on the frontend, like it happens right now.

@goldsky - any thoughts on that?

goldsky commented 9 years ago

I will try to figure out the solution