Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom Language Files (Idea) #5

Closed
tyupika93 opened this issue Oct 5, 2018 · 4 comments
Closed

Custom Language Files (Idea) #5

tyupika93 opened this issue Oct 5, 2018 · 4 comments

Comments

@tyupika93
Copy link

I find it a good idea to invite separate language files to invite texts.

for example

<TH> NAME </ th>
<th style = "width: 100px"> Injury </ th>
<th style = "width: 100px"> Value </ th>
<th style = "width: 150px"> Location </ th>
<th style = "width: 160px"> Links </ th>

instead of

$ langfile = array (
"NAME" => "Here is the text", // "sample");
"iNJURY" => "Here is the text", // "sample");
"VALUE" => "Here is the text", // "sample");

and say there would be a language folder where there would be a garage.php file whose content

define ("NAME", "Name");
define ("INJURY", "Injury");
define ("VALUE", "Value");

?>

From the language file you have been called to get the garage php file for all the text.

@ChristopherDay
Copy link
Owner

This is planned, I have yet to find an easy to implement solution to this. I need to find the time to go back and convert any strings to translation files.

@ChristopherDay ChristopherDay self-assigned this Oct 6, 2018
@vizubo vizubo mentioned this issue Jun 5, 2019
uaktags added a commit to uaktags/Gangster-Legends-V2 that referenced this issue Oct 1, 2020
@uaktags
Copy link

uaktags commented Oct 1, 2020

Started working on i18n support, chose to go without the composer package as a number of things had to be changed.
If you like it, d340877 starts to show that we can have languages in a few places: ./locale/{LANGUAGE}/translation.json is for the base install.
Then ./modules/installed/<module>/locale/{LANGUAGE}/translation.json is for each module to provide a translation.json set.
Right now I don't have anyway to block or deal with overloads, but by design in this Proof of Concept, each module would just create a new key within

{
"modules":{
   "module_name_1": { "term": "This is a term for module_name_1"}
  }
}

so each module would just append to the "modules" key and shouldn't ever affect each other. If you like this, i'll continue down this path, create a PR and push it out.

@uaktags
Copy link

uaktags commented Oct 2, 2020

module.json needs to be abandoned for textual things like menus if you want language files. Currently looking into a workaround solution.

@uaktags
Copy link

uaktags commented Oct 2, 2020

Think I solved this by following the idea laid out in loggedin.hooks.php, if the modules use hooks to provide the "info" array, then we can use PHP functions against the text and get back to supporting multiple languages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants