[Feature request]: Add information about existing language repo

[Jimmi08]

Motivation

When this happens:

Add at least link to github repo and you can find older translations there. For new one it looks like e107 doesn't have any translation

Proposed Solution

Remove limitation for translation version

If it is not possible, add information for new users about language repo and existing translations.

Alternatives

you need to know - most people don't know

Additional Context

No response

[rica-carv]

Furthermore, the languages in instaled plugins are not also cosidered, so no one ever knows if it exists or not a translation for a specific plugin....

[Moc]

Furthermore, the languages in instaled plugins are not also cosidered, so no one ever knows if it exists or not a translation for a specific plugin....

Please submit this as separate feature request

[rica-carv]

@Moc
Done
Let's see how long we have to wait....

[Moc]

@Moc
Done
Let's see how long we have to wait....

Well as you know it's an open source project, with only a handful of volunteers and everyone is doing things in their spare time. Any help that we can get is appreciated.

[tgtje]

my 2 cents : after examining 2 installs 1=2.3.3 and 1 = 2.4.x git
2.3.3 > displays available language packs.
2.4.0 > only the installed ones:

so to get the onlinelang packs (those which available at a certain version!!!!! ) the system checks which version is installed and thus creates the call for the lang packs of that same version.
Since there are for the git version = 2.4.0 or x) NO packs > ergo no listing.

I double checked the method by adjusting the corresponding file (;-)) running for test at 2.3.0 ( which basically IS a git 2.4.x version, but changed number) ehh voila all's there (see image)

so a alternate version check (fixed one for onlinelangpacks call could be a solution).. on that icludes preset + 1 or 2 earlier.

[CaMer0n]

@tgtje We could add that. The remaining issue is that if someone installs an old pack and a constant "LAN" is missing. It could break their entire site (particularly if using PHP8), possibly preventing access to the admin area as well.

[tgtje]

I fully agree ( i just edited).
maybe a 'flag' textual that this could happen > ergo 1 lower version is available BUT.. possibilty that...??? just brainstorming.
the warning (flag as red line block) on top of available..

(edit : idea behind : those will normally be added AFTER an install)

[Alex-e107nl]

This is a bit of a topsy-turvy world, it should just be that no errors in the code can bring down the entire website, certainly not the language files, if that can be caught, then it doesn't matter and you would just get a warning... that's my 2 cents...

[Jimmi08]

Because this is my FR, maybe solution:? :

• display all packs, disable install button of outdated packs
  or
• use developer mode for display all languages

[Moc]

Yeah I think your first suggestion would be best. With a message explaining why it's disabled.

Optionally we could also implement the second option for developers to to still install language packs, but not sure. For developers it may be easier just to clone the appropriate GitHub repository.

The issue is the way we use LANs, as constants, and the change in PHP8 to throw fatal errors. We'd need to catch those and ideally provide a fallback (English). This option may be best longer term but is far more complex to develop. For now I think we should stick to displaying the outdated version but not allowing it to download.

[Jimmi08]

Yeah I think your first suggestion would be best. With a message explaining why it's disabled.

Please, just use the class "disabled" in the install button. If you are a developer, you know how to install something that is disabled :)

Optionally we could also implement the second option for developers to to still install language packs, but not sure. For developers it may be easier just to clone the appropriate GitHub repository.

Agree. The goal was to know about those packs. Link to repo could be useful too.

The issue is the way we use LANs, as constants, and the change in PHP8 to throw fatal errors. We'd need to catch those and ideally provide a fallback (English). This option may be best longer term but is far more complex to develop. For now I think we should stick to displaying the outdated version but not allowing it to download.

This is already solved for templates with {LAN}.

There is a preference for loading English files if the native file is missing. I think that this is the wrong approach with PHP 8 around.
My opinion is that English file should be loaded always after the native file but changed with if not defined... define... This way you don't need to use a shortcode for each constant (performance). If I am not wrong, you started to use {LAN} with parsing outside templates... Bŕŕŕ... This would simplify loading lan files too.

[rica-carv]

The problem is that you still have both ways to display a LAN, and can't control how it's called, so if you keep calling LAN's via the constant and not using the shortcode....