Download the PHP package slendium/localization without Composer
On this page you can find all versions of the php package slendium/localization. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download slendium/localization
More information about slendium/localization
Files in slendium/localization
Package localization
Short Description A Slendium recommendation on handling localization across libraries and frameworks.
License MIT
FAQ
Example:
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 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.
Informations about the package localization
Localization
An implementation-agnostic standard for localization in PHP. It is intended to facilitate the exchange of localizable information between PHP frameworks and libraries. The primary motivation for creating this standard is to provide common interfaces for other Slendium libraries, so it will be biased towards these use-cases. Suggestions are always welcome.
Requires PHP 8.4+ and assumes the same standards that PHP uses natively (RFC 4646, CLDR). It also assumes use of a static analyzer such as PHPStan.
The problem
There are different ways of doing localization in PHP (array dictionaries, gettext, framework-specific implementations, etc.). Sometimes end-users can enter their own translations on a per-object basis - for example, using a database table. Code that is responsible for producing a locale-specific output (such as an HTML page, a JSON object, a PDF, an e-mail, etc.), or other libraries that want to work with localizable objects, should not become dependent on the underlying dictionary implementation of such objects. Common interfaces prevent this dependency.
Example of a basic use-case
Consider the following application-specific object which has a $name property that should change based on the current locale.
Now consider the following class for generating an outgoing e-mail. Imagine EmailGenerator is a template class provided by a framework which returns an intermediate representation of the structure of the e-mail to be sent. The framework will later convert this structure to the actual text to be sent, using a localization algorithm of its own choosing. The implementor of this API does not have to worry about the specifics of localizing this e-mail, but can focus instead on its general structure. From their perspective it does not matter whether the text comes from a static dictionary, a database object or even an external source.
Post-processing
Work in progress.
Fallback values
Work in progress.
Pluralization
Pluralization has been left out of this standard, but may be added later if a good case can be made.
All versions of localization with dependencies
ext-intl Version *