Download the PHP package mindplay/lang without Composer

On this page you can find all versions of the php package mindplay/lang. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package lang

mindplay/lang

This library implements an ultra-simple, super-lightweight localization facility. (~100 SLOC)

PHP Version Build Status Code Coverage Scrutinizer Code Quality

It consists of a single pseudo-namespace with just a few functions, but affords a surprising amount of flexibility, including the ability to handle plurality, such as "1 result" vs "5 results", without the (mental or computational) overhead of inventing any proprietary syntax.

Concept

Strings are translated from english source text, optionally with name/value tokens being replaced.

Alternatively, you can use keys instead of english source text, e.g. NUM_RESULTS rather than {num} results - this is solely a matter of convention, and has no bearing on how the translation mechanism works, you just need to understand the pros and cons of each strategy:

Translations are grouped into "translation domains", which map to subfolders and plain PHP files, e.g. one file per every domain/language pair.

By convention, your base translation domain should be your Composer package name, e.g. {vendor}/{package}, optionally with translation sub-domains nested below those - following this convention obviates the need to bootstrap with lang::register() at all, if you follow the convention of placing a folder named lang in the root of your Composer package.

The whole thing is static, and if that makes you quibble - relax. Translations are after all global, in the sense that there's only one translation of each string for any given language.

Usage

To translate a string, simpy do this:

By default (without any configuration; see below) this library will load the file vendor/foo/bar/en.php - the language file format will be discussed below.

To change the active language, do this:

To obtain a string in a specific language (ignoring the active language) use the translate() function:

Alternatively, you can obtain a translation function for a specific language domain, and reuse it:

This can be useful for dependency injection, or just to avoid repeating the language domain name for every call. Note that an optional second argument for the language code will give you a translation function for a specific language. Also note that language files will not actually load until the translation function is used - so there are no unpredictable performance implications.

Assuming you follow the convention of using your Composer package name as your root language domain, and placing your language files in a folder named lang in the root of your package, you do not need to call lang::register() to configure the root path - the package will use composer-locator to automatically find the root path.

In other cases - or in cases where you wish to override the translation files of an external package in your project - you need to register the base path of the translation files for the language domain - for example:

Now, if you call lang::text("foo/bar", "..."), the translation file {__DIR__}/lang/en.php will be loaded - the file name is the two-letter language code. If you call lang::text("foo/bar/baz", "..."), the translation file {__DIR__}/lang/baz/en.php will load, and so on.

A language file such as lang/baz/en.php might look like this:

This example demonstrates the two forms of translation - using plain strings with curly-braced placeholders for replaceable tokens, or using anonymous functions; in the latter case, tokens are mapped to matching argument names, which enables you to implement language-specific logic for things like plurality.

Refer to the inline documentation for additional details.


All versions of lang with dependencies

PHP Build Version
Package Version
Requires php Version >=5.4.0
mindplay/composer-locator Version ^2
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package mindplay/lang contains the following files

Loading the files please wait ....