Tag Archives: serbian-latin

tobifjellner (Tor-Bjorn Fjellner) 8:09 pm on October 7, 2020
Tags: , serbian-latin   

Meeting invitation: Revisiting Serbian Latin

Let’s have an extra meeting on Wednesday October 14, at 17:00 hrs UTC (Wednesday, October 14, 2020, 17:00 GMT), about how we best can serve a Latin version of Serbian, and what steps need to be taken in order to reach there.

We’ll have the meeting in our own SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel “polyglots”.

All background information and initial discussion is available in https://make.wordpress.org/polyglots/2017/12/07/revisiting-serbian-latin/

#polyglots-meeting #serbian-latin

Hew 1:50 pm on December 7, 2017
Tags: serbian-latin   

Revisiting Serbian Latin

Hi Polyglots!

I’d like to reopen discussion on adding a discrete Serbian Latin localeLocale Locale = language version, often a combination of a language code and a region code, for instance es_MX denotes Spanish as it’s used in Mexico. A list of all locales supported by WordPress in https://make.wordpress.org/polyglots/teams/. We seem to have last addressed it in 2012. I think it’s worth considering adding here circa 2017 for a few reasons:

1. We now are in a very async world (eg, JS callouts) and the transformative plugins that tend to be suggested do not handle asynchronous pieces well. We see the problem with Jetpack Comments (as noted by eboye previously) but the same issue presumably extends to any theme or pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party making async calls.

2. Conceptually, IMHO, having a discrete entry designated is the “right thing to do” programmatically. It helps dependencies (plugin, theme, etc, as noted in 1) be accurate which concretely ends up meaning less bugs.

3. Official GP variant support is coming so we might as well be prepared.

4. `de-formal` established a discrete variant precedent.

5. A Serbian Latin GP project should require no additional validation resources as we could simply cron job transliteration of Cyrillic to the Latin project every few hours.

Thoughts?

#serbian-latin