GetSimple Support Forum

Full Version: Generic language terms
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I want to add some generic language tokens to core.

Ideally this will make multi language incorporation for plugin authors a little easier.

So I am building a list of generic terms.

We already have quite a bit in our language file, but they are defined per page and you have to check to find them all over the place as they were not designed to be generic.

To start this is what I have so far, input welcome.

Code:
/*
* Generics
*/
"TITLE"         => "Title",
"DELETE"         => "Delete",
"REMOVE"         => "Remove",
"FILE"             => "File",
"FOLDER"         => "Folder",
"DIRECTORY" => "Directory",
"CLOSE"         => "Close",
"OPEN"            => "Open",
"NEXT"            => "Next",
"PREVIOUS"    => "Previous",
"BACK"            => "Back",
"TOP"                => "Top",
"BOTTOM"        => "Bottom",
"LEFT"            => "Left",
"RIGHT"            => "Right",
"UP"                => "Up",
"DOWN"            => "Down",
"REDO"            => "Redo",
# "UNDO"            => "Undo",
# "YES"                => "Yes",
# "NO"                => "No",
"RESET"            => "Reset",
"SAVE"            => "Save",
#"EDIT"            => "Edit",
"SHOW"            => "Show",
# "CANCEL"        => "Cancel",
# "DESCRIPTION" => "Description",
"STATUS"        => "Status",
# "ERROR"            => "Error",
"SUCCESS"        => "Success",
"FAILURE"        => "Failure",
"PASSED"        => "Passed",
"FAILED"         => "Failed",
"INFO"            => "Info",
"WARNING"        => "Warning",
"ALERT"            => "Alert",
"MESSAGE"        => "Message",
"PRINT"            => "Print",
"VIEW"            => "View",
"REFRESH"        => "Refresh",
"DOWNLOAD"    => "Download",
"THEME"            => "Theme",
"COMPONENT"    => "Component",
"PLUGIN"        => "Plugin",
# "NONE"                            =>    "None",
# "PAGE"                            =>    "Page",
"TOTAL"            => "Total",
"COUNT"            => "Count",
"ADD"                => "Add",
"NEW"                => "New",
# "DATE"            => "Date",
"DAY"                => "Day",
"MONTH"            => "Month",
"YEAR"            => "Year",
"GOOD"            => "Good",
"BAD"                => "Bad",
"PASS"            => "Pass",
"FAIL"            =>"Fail",
# "OK"                => "OK",
"ITEMS"            => "Items",
"LIST"            => "List",
"ORDER"            => "Order",
"MENU"            => "Menu",
"LOG"                => "Log",
"GEN_ENABLE" => "Enable",
"GEN_DISABLE" => "Disable",
"ENABLED"  => "Enabled",
"DISABLED" => "Disabled",
"ACTIVE"     => "Active",
"INACTIVE" =>    "Inactive",

Sorry its not alphabetized
Great idea!

Another part could be the localisation of dates and times, which BTW GetSimple should format with strftime instead of date, as the latter does not allow the localisation of weekday and month names.

e.g.:
'LOCALE' => "de_DE.utf8,de_DE,de",
'DATETIME_FORMAT' => "%A, %d.%m.%Y - %H:%M",
'DATE_FORMAT' => "%A, %d.%m.%Y",
'TIME_FORMAT' => "%H:%M"
(multiple locales as they are not the same across systems - try until one works; format for strftime)
How a generic translation file should be implemented anyway ?
Should it stay as an independed file in /admin/lang, and be included automatically into plugin's core ?
Or work independently from the plugin? For example, when a plugin translation file doesn't contain a phrase, GS would seek if there's a variable in generic file ?

Mvlcek touched important question, as the problem with dates has never been resolved.
I'd add to it that there's not only one date format being used in a country, and we might end with a numeric date like day.month.year - f.e. 10.03.1982 - as well as with month's name - f.e. 10 january 2001 (as it goes with polish country).
Users should have a possibility to choose a date format under GS settings. A preformatted dropdown list would be the best option in my opinion, would be unified for all countres, and contain all possible time formats. The rest stays in plugin's developers hands.
yojoe Wrote:How a generic translation file should be implemented anyway ?
Should it stay as an independed file in /admin/lang, and be included automatically into plugin's core ?
Or work independently from the plugin? For example, when a plugin translation file doesn't contain a phrase, GS would seek if there's a variable in generic file ?

These translation can be included in the standard language file of GetSimple.
As for a plugin, it's rather like if it is a general phrase from GS core, the plugin can use it, otherwise it needs to use an entry from the plugin specific file. I'm doing this already in my plugins for terms like "Delete" or "Cancel".
Nothing special , just language tokens in the normal core lang file. Has nothing to do with plugins, plugin authors can do whatever they want regarding i18n merges and translations. These will just be built in as helpers, authors can incorporate them without having to make their own language files etc.