The new implementation of /data/lang/strings.yml unfriendly to languages with different gramatical order

[jiaye-wu]

Since it is more a multi-language-specific problem, I feel it might be more appropriate to mention it here than in al-folio.

In the new release 1.14.4, the implementation of localization feature (text display) under blog -> click a tag to filter -> "an archive of posts/books in this category/with this tag/from this year" changed in a fragmented way with a fixed order, such that it is very unfriendly to languages with a different gramatical order than European languages.

Here is an example. The left is the new implementation that separates gramatical elements. The right is the old implementation where the users can use a whole sentence regardless of gramatical order of elements. The elements with the same number has the same meaning.

As can be seen here, for Chinese, the new implementation is near-totally unusuable, for the order of elements is inversed, and the element "1" can be ignored. I can think of a dirty-workaround-type of translation that is grammatically correct in Chinese, but it is unnatural -- it forms a phrase with bracketed notes. Here is a workaround for Chinese users:

prefix (1)	colletctions (2)	suffix (3)
筛选的	文章/书籍	（按年份/标签/分类）

which is quite awkward to me. Also, the new search/filter code adds a white space between element 1 and 2, and in Chinese we don't have any white space in our phrases and sentences.

I understand that the new implementation might be flexible for adding future functions/features, but I think it saves neither lines nor words/letters. For the new implementation, 8 lines are used; while if we simply use the old method (a sentence), then it is only 6 lines and future-added features will not interfere with the old features.

My suggestions would be, if we can fall back to the old implementations (sentence-based). There are other languages in the world that has a different order, and using a sentence other than separation at gramatical elements makes more sense in terms of generality.

[george-gca]

I updated this just to showcase how someone can use a single file if it wants to, since this can be done because of jekyll-archives-v2. But I get your point.

I don't think we can fallback to the previous solution that easily because of the newly introduced books collection. I tried to create prefix and suffix strings so these could be used for all possible collections that use the archives pages. How would supporting multiple collections work for you? Like the current books and posts? How would you prefer the strings to be?

Also, the new search/filter code adds a white space between element 1 and 2, and in Chinese we don't have any white space in our phrases and sentences.

I don't understand. Can you elaborate more on that?

[jiaye-wu]

Thank you for your reply!

How would supporting multiple collections work for you? Like the current books and posts? How would you prefer the strings to be?

The problem is that, if we use a prefix-main-suffix structure, the number of "branches" of each part is also varying from language to language. For example, in English, the sting "an archive of + books/posts + in this category/tag/year", the prefix has a fixed term, the main part has 2 branches, and the suffix has 3 branches. In Chinese for example, "在此分类/标签/年份下的 + 文章/书籍 + （的过滤结果）", the prefix has 3 branches (category/tag/year), the main part has 2 branches (books/posts), and the suffix is fixed or optional (leave blank).

I don't know if other languages will feature more parts or a different order, which means sentence-based localization, like the other parts of strings.yml, is more flexible.

I don't understand. Can you elaborate more on that?

The new implementation adds a space between element 1 ("prefix") and element 2 (main), and beween element 2 and 3 (suffix). If I use my dirty fix, my Chinese translation is displayed as "已筛选的 文章 （按所选分类）". However, "space" is also not a universal thing among languages. In proper Chinese, "space" doesn't exist (except for very rare usage case to emphersize something, but is informal), and the correct way is to write them together, "已筛选的文章（按所选分类）".

I mean, this exposes another problem of language generality... and sentence-based translation fix all these issues.

[george-gca]

But we can't implement it in the same way as before because of the new collection. Previously we only had one collection posts with archive support, now we also have books. So, we had it like this:

archive_category: an archive of posts in this category
archive_tag: an archive of posts with this tag
archive_year: an archive of posts from this year

One possible solution could be to create one such set of strings for each collection. Is this your suggestion?

posts_archive_category: an archive of posts in this category
posts_archive_tag: an archive of posts with this tag
posts_archive_year: an archive of posts from this year

books_archive_category: an archive of books in this category
books_archive_tag: an archive of books with this tag
books_archive_year: an archive of books from this year

I don't quite like this, but I don't have any other idea jumping from my mind right now. Any suggestion?

[jiaye-wu]

Yes, this is exactly what I meant, using set of strings for each collection. Like I said, this solution is shorter in terms of lines and codes (the one you used to realize serach and filter function), and when introducing new features/collections, let's say, 'films', it will not interfere with the old collections and cause new problems.

I agree, it is not very elegent, but I think it's better not to play with grammatical elements. Many localization realizations are simply using one string in language A to replace another string in language B and they work well.

If I can think of something more elegent, I'll share it with you.

[george-gca]

I'll give it a thought to see if I can come up with a better solution. If not, I'll implement these changes.