[RFC] Wish/todolist for the extension about translate HOT 22 CLOSED

This is a big maybe, but I have a feeling, it will come up in the future anyway:
For now, we use a locale slug to determine the current language. But there are at least two other ways of doing it:

• Via domain (mysite.at -> German, mysite.com -> English or at.mysite.com -> german,...)
• Localized contenttype slugs only (mysite.com/about-us, mysite.com/ueber-uns)

from translate.

Yeah, for me "Check that we can support all extensions that add fields" and "Better and more thorough documentation" are the most important, after that "Automatic unit tests"... Do you agree?

from translate.

As I've recently started using this together with boltforms, I'm wondering if you have intentions to change your translating approach. You personally referred to your current solution as "hacky".

The reason I'm asking is because fiddling around in templates of other extensions seems like rather fragile approach as a single update could throw things off. I'm curious if you were already thinking of using a different approach to build upon other extensions.

Let me say this first: the current solution works, but I'm wondering how desirable it will be in the long run.

from translate.

@Puddingboy: Yeah, my plan is to change that completely. Regarding the updating issue, you can have the form template in your theme folder, so it's not overwritten by any updates to boltforms.

from translate.

First, thanks for taking such great care of this extension. I currently have some bolt projects coming my way again, so expect more participation on my part. Except for the automatic google translation, i find all your points interesting. I'll go through your code later this week and see, what i can add and support.

As for the automatic translation: It it runs server-side, it has to either cached or delays the load time of the side. Also automatic translations often still are strange, so they need human checking first. One option would be, to allow fetching translation for one specific field in the backend via click on a button and async js call. But in my eyes, its not really worth the effort. What do you think?

from translate.

@madc Yeah, that one isn't that high in my priorities. I was mostly thinking of what features we might want and thought it might be useful in some edge cases. I'll cross it out for now, and if someone requests it we can reconsider.

from translate.

I think, we should add automatic unit tests to the list. Heard, it looks good to have them.. :D

from translate.

@madc Yep, definitely... I'll be looking at boltforms to see how we can make that happen, since it will require hooks into bolt.

from translate.

The domain style is very possible today from just the routing.yml file, since one can set defaults based on hostname requirements (it just requires more copypasting :D ) but it might require us wrangling bolt to get it to "get" which is the canonical route for a piece of content, the localized contenttype slugs only style is harder and will require some more modifications to the storage overrides, but not impossible. So definitely something for us to look into!

from translate.

This things have no real priority for me, and you're right, domain based routing is possible by configuration. Maybe we split the todo list into "Near future" and "Distant future" and put it on the second one.

Personally I'd avoid contenttype slug-style in projects as good as I can, so I'm fine if we decide, we don't want to implement it at all.

from translate.

I haven't installed Bolt-Translate yet, but I'm about to test it the coming days.

After figuring out what you mean with "the localeswitcher Twig function" I was wondering whether _my_localeswitcher_template.twig is going into the theme directory or into a separate location in the extension directory somewhere.

What I have done so far with multilanguage sites where e.g. a certain Dutch record has not been translated into Swahili, is letting the "Swahili" link go to the Swahili homepage. I should manage to create something like that with Bolt-Translate too, but I would appreciate an example in the docs.

What might be good to put in the docs for the lazy: pre-cooked examples like how to make tags like
<html lang="en"> <meta http-equiv="Content-Language" content="en">

Probably more feedback due soon. Great work, by the looks of it!

from translate.

@evertalbers the "_my_localeswitcher_template.twig" template usually goes in your theme folder, but you can call it anything and put it anywhere that is a loaded twig path.

Currently bolt-translate can handle single-locale records, but it still needs a lot of polish. For example menuitems aren't checked if they exist in the current locale IIRC. If you find any issues regarding this or anything else please feel free to report them here.

Adding proper html lang headers is on my to-do list, but I'll add it here to. I also planned to have it automatically add rel="alternate" link tags to the header but that must have slipped my mind somewhere along the way...

from translate.

@evertalbers Thanks for taking the time and for providing some feedback!
@SahAssar Wouldn't it be enough, to put a how-to about the rel="alternate" link tags in the documentation. Its quite easy to archive, isn't it?

As for the twig function, I'm again thinking about getting rid of it. Now with the global variable, a handful of well documented code snippets should do the job.. but I'm flip-flopping on that one. Personally I'm only using the global variable.

from translate.

function suggestion: A way to unroute translations if empty so that translations can be added later if needed. It would also make sense to have a config option to set behavior as default and overlap this with the same functionality on individual records so that I can hide a yet to be translated record if needed.

As for now I have little clue how this would be best implemented. a checkbox per locale or a record for example or split draft selectboxes or maybe even a checkbox on top of the localeswitcher. I don't know.

Just wanted to throw this out there.

from translate.

@madc Yeah, the rel tags would be easy to add to the docs, but I think the default should be that they are added automatically. I'd like to keep the setup to a minimum... I'd be totally okay with removing the function though, since one has to edit the template for that anyway and we can't predict where someone wants to put it.

@Puddingboy The idea is to make it so that records that haven't been translated don't show up in menus/other places. We can do this just by checking if a slug has been added for that particular record, but having something like bolt's own record statuses might be a good idea too...

Thanks for all the input guys!

from translate.

To clarify: some people would want all their translations shown by default and others prefer to have them hidden by default. If you overlap this with ui element to toggle them on each record you'll be golden.

That way you get to fill the void of "there are always exceptions".

now something else: add locale tabs on ct summary pages too so that you can sort on each language? possible or perhaps too optimistic?

from translate.

I'd like to move the discussion about fallback content to #65.

from translate.

How is it going with the wishlist at this point? Hit me up if you feel like testing new stuff :)

from translate.

@Puddingboy Sorry, I haven't been able to work on it much lately, too much other work stuff going on :(

from translate.

Is it perhaps possible to keep the hash in the URL when switching languages?

For example:

• my URL is "example.org/en#hash1"
• I change to a different language (e.g. french) by using the localeswitcher
• now my URL is "example.org/fr". I want it to be "example.org/fr#hash1"

Just a suggestion. I suppose it isn't that much to implement, but I can't be sure.

from translate.

Just clarifiying here since we already talked about this on slack, but this isn't actually possible. The fragment identifier isn't actually sent to the server, so the only way to do it is with JS and I'd prefer to not involve client-side scripting in this extension. If you want to PR an addition to the readme for how to do it with JS that'd be welcome though. It'd probably be something like this (I prefer to not require jQuery if I can help it):

Array.prototype.forEach.call(document.querySelectorAll('.localeswitcher a'), function(elem){
    elem.href = elem.href + window.location.hash;
});

That is not tested and is if the localeswitcher has the class localeswitcher, by default it has none IIRC.

from translate.

Closing this, the remaining points will get done when there is time or in the next rewrite.

from translate.