Translation : not translated strings & French fix

chezyann

Hi,

First I'd suggest a fix concerning the French translation :
"logout": "déconnection", should be "logout": "déconnexion",

Second, some strings can't be translated using translation json files (login/password placeholders for example). Is it going to evolve ?

Best regards

Karl

Hi! Sorry, was busy releasing the new version 0.5.0 ...

chezyann First I'd suggest a fix concerning the French translation :
"logout": "déconnection", should be "logout": "déconnexion",

I have now changed this officially ready for next release 0.6.0. If you want to fix it for your current Files app, you can use javascript config to merge custom language items. In your case, it would look like this:

_c.config = {
    lang: {
        langs: {
            fr: {
                logout: 'déconnexion'
            }
        }
    }
}

chezyann Second, some strings can't be translated using translation json files (login/password placeholders for example). Is it going to evolve ?

Several lang items were updated in latest release, while some items remain missing in language JSON files and/or simply remain in English until we get official translations. Read more:
docs/language/

As for "login/password" placeholders, this is a different issue because the login page is currently contained in the main index.php file without translations. In the future, it will be moved to Javascript and will be able to use multi-language translations. To fix the login page texts, you would currently need to edit index.php from around line 325 where // login page starts.

Karl

chezyann Second, some strings can't be translated using translation json files (login/password placeholders for example). Is it going to evolve ?

Jibap

Hi !

Amazing v0.12 !! it is a very good job.

I'd suggest a new text in config modal : in place of "Cancel/Annuler" button > "Close/Fermer" because when you edit some params, the only one button to exit modal is "Cancel/Annuler" which is ambiguous, it suggests that the changes will be reverted...

While I'm here, I think there is an error in the 0.12 presentation article: you wrote in "New Javascript Options" in header

_files/css/custom.js

it should be
_files/js/custom.js

no ?

About theses new options, i tested that :
_c.config = { login: { on_logout: "refresh", } }

but it not works, i stay everytime on login form (while i have a public access 🫤)

Karl

Jibap I'd suggest a new text in config modal : in place of "Cancel/Annuler" button > "Close/Fermer" because when you edit some params, the only one button to exit modal is "Cancel/Annuler" which is ambiguous, it suggests that the changes will be reverted...

I assume you mean change to "Close/Fermer" ONLY for the settings editor, and not for all other action modals? The only problem I have with this, is consistency. At least for English, this doesn't seem reasonable, considering all other action modals close with "cancel". It's pretty obvious that this button will close the modal. Even if you have already edited settings, this would already have been notified with other visual signals (toast). It shouldn't make sense that clicking "cancel" would undo changes that have already been made anyway. For consistency and standard, I think we need to stick with "cancel". The modal can also be closed by (ESC) and clicking outside the modal anyway.

Jibap it should be
_files/js/custom.js

Thanks, fixed.

Jibap About theses new options, i tested that :
_c.config = {
login: {
on_logout: "refresh",
}
}

but it not works, i stay everytime on login form (while i have a public access 🫤)

There might be a simple typo bug with refresh option while I was testing. I will look into it. There will likely be a 0.12.1, please have patience. It's not however clear what you mean "i stay everytime on login form". When testing from here with refresh, nothing happened (which would be correct according to the bug).

Why not keep the default form option anyway? This allows fast re-login, and will proceed to automatically logout if someone cancels the login.

Jibap

Karl I assume you mean change to "Close/Fermer" ONLY for the settings editor, and not for all other action modals?

Yes of course, sorry.

Karl Why not keep the default form option anyway?

I don't know which is the good option to return to the home URL, i suggested "refresh" but not sure... i have only public access and admin access, so when i logout i prefer to be redirected to public access to check if my edit are OK.

Karl

Jibap I don't know which is the good option to return to the home URL, i suggested "refresh" but not sure... i have only public access and admin access, so when i logout i prefer to be redirected to public access to check if my edit are OK.

It seems you may have misunderstood. The on_logout option decides the event that triggers when you are logged out by timeout (from server), which is detected internally in Files Gallery. In this case, it makes sense for the user to be able to re-login immediately, as it's unlikely they wanted to get logged out in the first place. This event however does NOT get triggered when you CLICK the logout button, in which case you simply get logged out, and that's it. There are no options.

I guess what you are asking, is that when you click the logout button, you want to be redirected to the public version instead of seeing the login page? Keep in mind, you can just click the "cancel" button on the login page to continue to the public version without logging in. I think it's important to intentionally show the login-page after logout, so that it's clear to the user that they have been successfully logged out. If the page just refreshes looking almost the same, it might not be clear to the user if they have been logged out or not.

Jibap

Oh yes, you'r right !
I've seen that "cancel" button can redirect to public view if it exists.

Maybe a new option for that soon ? 😉

Karl

Jibap Oh yes, you'r right !
I've seen that "cancel" button can redirect to public view if it exists.

It's working, right?

The "cancel" button on the login form will always exist as long as there is a non-login (public) version. If the main config is password-protected, there will only be a "login" button, because it's not possible to view the gallery without logging in.

Jibap Maybe a new option for that soon ? 😉

You mean "logout" button simply refreshes the page without showing the login form? Yes maybe.

Karl

Jibap Maybe a new option for that soon ? 😉

I looked into this, but it's not something we can include as a Javascript option, because ?logout=1 must be handled by PHP to actually log out the user. For now, you would need to edit index.php code on line 300:

// allow ?logout=1 parameter only if user is already logged in
if(U::get('logout')) return $this->form();

Change to:

// allow ?logout=1 parameter only if user is already logged in
if(U::get('logout')) {
  // display the login form only if login is required
  if(self::$has_public_login) return $this->form();
  // make sure to log out the user
  foreach (['username', 'login'] as $key) unset($_SESSION[$key]);
  // return, so that the app can continue in public non-login mode
  return;
}

I'm not gonna implement this officially, but let's see if any other usage cases or requests for this come up.

Jibap

Karl It's working, right?

Yes

Karl The "cancel" button on the login form will always exist as long as there is a non-login (public) version.

Great !

Karl Yes maybe.

Very great😝

Jibap

Thanks a lot. I anderstand your view.