Settings : default language selector

[jcookson-infoblox]

Is your feature request related to a problem? Please describe. There is no means of specifying a specific language as the default language. So, when I search for meetings that are in Spanish, its assumed all non-language selected meetings are english. That may not be the case going forward.

Describe the solution you'd like A default language selector on the setting page.

Describe alternatives you've considered Appending import files that checks for specific languages and if not auto adding ("E") to the type listing on import. Otherwise, having to manually edit all 4000+ meetings for my area.

Additional context I just attended PRAASA recently and am a member of NAATW and it occurs to me that technology and AA would be more friendly if meetings/districts/areas could set this in one place and then import all their meetings. If they are a part of a feed, then when shared it could be easily presented to the larger whole. Otherwise, we risk alienating already diasporic entities that may feel that unless they speak EN then they cannot be a part of.

[jcookson-infoblox]

Same for non-imported meetings as well.

[tech2serve]

Default language for the site is set in the Wordpress settings. So I don't believe your problem statement is accurate in that sense.

Yes, TSML assumes the default language for meetings is the language set for the site. So in Poland, for example, they set the site language to Polish and the meetings are assumed to be in that language. That assumption seems to work.

Some languages can be chosen and searched for using types. While this is not ideal, it generally works I believe.

(Note: Personally, long term, I'd like to pull a lot of the "types" we have out of that and put them into different groupings. This approach comes at a cost however, and so I'm not sure we'll get there any time soon.)

In either case, the language is set for the site is set site-wide, and I don't see any benefit of adding it also to our plugin settings. Perhaps you can elaborate on this statement?

That may not be the case going forward.

[digimech]

Reading the comment, I believe the request is to set the preferred language at the meeting level - this way filters can be set for the particular preferred language of the specific meeting. Personally, I think this has benefit e.g., if we want to build out a Spanish-language landing page and have meetings pre-filtered for that preference.

[jcookson-infoblox]

you are correct @digimech ...

[jcookson-infoblox]

idea is that the meetings list has a default language .. so all newly imported or re-imported meetings have a language set to the default -- if there is not a language already set. default language = E (english) case 1 : new meeting - meeting X1 @8am Monday, no lang set -- imports with E as language (it is auto-added because nothing was set) case 2 : existing meeting - meeting Y1 @ 9am Tuesday, ES set -- imports with ES set because the language type was added as an item in the types for the meeting. case 3 : non-imported meetings : since meeting was not imported & system can sense that, should check for language types and if none selected should auto-set checkbox to default language.

these would be basic cases ...

[jcookson-infoblox]

[tech2serve]

Reading the comment, I believe the request is to set the preferred language at the meeting level - this way filters can be set for the particular preferred language of the specific meeting. Personally, I think this has benefit e.g., if we want to build out a Spanish-language landing page and have meetings pre-filtered for that preference.

This is already possible with the current implementation of TSML.

The site's default language is the default for all the meetings unless the admin sets a language using an existing or custom type. Several languages are already included in the plugin, and each site can add custom types as they wish.

These types can then be used in formatted search queries (see our FAQ) to create links that can then be set as pages in Wordpress.

Don't get me wrong, there is a bigger discussion here about support for other languages. And as I said above, I don't like having all of the types we have already. The list has become unwieldy and tries to do too much. We need to pull groupings out (i.e., languages, meeting status info) out of the types and move them to different categories. IMO, types should be more narrowly defined to the traditional meeting formats (although that ship has sailed). Now imagine if we started adding the hundreds of different languages (let alone dialects).

In this sense, the approach @jcookson-infoblox is proposing may be the right one long term, but the problem for a website, as stated, it is already solvable inside TSML, this isn't the right forum for the discussion.

The part that doesn't work today for this is with Meeting Guide. GSO would need to agree to adopt his proposal (or something similar. But PLEASE, not as a meeting type) as part of the spec and then we meeting information providers can implement that standard.

@jcookson-infoblox I'm willing to help represent this issue (as restated) to GSO but not as additional meeting types (as you've proposed in the specification repo). I'll make a request over there about how to handle those.

@code4recovery/tsml-contributors @L-squared

[jcookson-infoblox]

happily accepted.

[jcookson-infoblox]

As a side note, the reference about the amount of langs. I just checked out the ISO 639-2 listing of language & dialects and its huge (https://www.loc.gov/standards/iso639-2/php/code_list.php) ... while it would allow for the internationalization of the platform, it would have it inherent issues.

[tech2serve]

As a side note, the reference about the amount of langs. I just checked out the ISO 639-2 listing of language & dialects and its huge (https://www.loc.gov/standards/iso639-2/php/code_list.php) ... while it would allow for the internationalization of the platform, it would have it inherent issues.

Precisely. And as much as I hate to say this, many of the language issues described are fringe cases involving a tiny number of users.

And most areas that have languages outside of the country norm have established protocols for handling this.

A few years ago, I traveled to Europe and found they had established a separate region for handling English-speaking meetings.

My point is that getting priority with this situation may be difficult.

[jcookson-infoblox]

totally understood. this item is something that the body will likely defer to GSO for come form of guidance on - or at least guidance from the team that manages the 12 step meeting app @ GSO. the implementation from code4recovery not only affect AA meetings, but other fellowship's meetings as well -- so the solutions here , has other mitigating factors for consideration.

locally, I asked the intergroup offices about this and one of them offered to add to their export file (which we pick up and inject via the import tool) EN to the types as the default lang, unless another language was actually selected.

[tech2serve]

I'm going to close this issue for now and track it as part of the spec discussions we're trying to create with GSO.

Currently most of the people who have been in the discussion agree with some sort of separate field outside of types, or a "hierarchy of types", although I suspect flat will win as it is less complicated and quicker.

By all means, keep us informed of how you all do this.

And what website are you working on? I'd like to take a look at how you're mixing languages.

Thanks.

[jcookson-infoblox]

area72aa.org. because they are checkboxes, we can choose any/all/or none for language.

[tech2serve]

Hey James, I missed your reply to this, and just now happened to check.

I see where you are making the site available in English or Spanish using Weglot (which is neat).

I am guessing the checkboxes are on the backend.