Design Principle: People-Friendly vs. Machine-Friendly

[stasm]

A dedicated issue for discussing one of the design dimensions proposed in #50.

People-Friendly vs. Machine-Friendly

If we end up defining the syntax for messages, who should the target group be? Do we expect people to read it? Edit it? Write it from scratch? Are those people developers, project managers, localization engineers, linguists, translators?

Related Issues: #48

[stasm]

@echeran Do you think we could use this issue to talk about the data model vs. syntax question we discussed last week? Or are these two separate dimensions?

[Fleker]

Technical writers can become effective with writing syntaxes like markdown and some basic HTML. While there may be abstractions in GUI-based tooling, I think having the ability to open and modify the files directly would be useful for some localization folks. At the same time, I don't know that it necessarily means we have to have a significantly simple design.

[echeran]

@stasm I think data model vs. syntax question is separate.

For example, if we want to create a declarative query language, we can come up with syntaxes like SQL, LINQ, Datalog, etc. My strong opinion, confirmed to me by experience, is that SQL is inferior to Datalog / LINQ and that is in part because it was designed for humans and not machines. They all implement the same functionality but behave very differently. You could imagine a data model for the input of a query as a separate consideration, and you could imagine data-oriented way to write your query, or something in between. So this example illustrates to me how the principle of syntax design is orthogonal to the principle of whether to have a data-oriented design or a syntax based design.

[joeyhub]

I don't think this is always an easy solve. ICU sometimes is the bridge rather than a side of it.

When I'm using ICU I want something that I am giving both to the machine and to a translator.

The translator can be taught something but I don't expect them to have to become a programmer. Currently it's simple enough that you don't need to be a linguist or a programmer to master it.

Even where ICU is a bit complex it's one standard and if widely used has a very good cost ratio for learning it.

If the syntax and semantics are in response to the syntax and semantics of language then on some level the translator already knows it already from knowing their language.

My personal feeling is that it's the nature of the language and handling that which would be the strongest driver for complexity.

I've picked up some legacy code though and seen lots of translations as well as systems with many things that I have not seen ICU handle directly.

I'm not sure it's always easy to juggle man versus machine without more concrete cases or examples.

It's fairly common to have systems that can build different strings and places where layers or structured translations are needed. I'm not sure if this is an area that could come under focus.
It tends to lead to more fragmentation with it often being unclear in the sources how a string is composed.

I've seen someone implement a custom handler for Polish rules around numbers which appears so specific but complex and detailed that I don't think normal rules or syntax and semantics can handle it.

Some cases such as these could be handled with custom formats including the ability to format things such as literals. At present when it comes down to it the ICU format is more about templating strings in an advanced way a bit of a simplification of a view format with the most common generic programmatic elements required for typical intl scenarios.

I've seen much higher level solutions that have internals that parse the language but I found these harder to work with in practice. Latex has this magic thing where you load a module and it tries to internationalise your document. That's not just aware of the rules extensively but implicit as well and is parsing the content itself to work out action rather than only doing what it's told (declarative).

For example it will try to parse the language then to make specific to another region might change "Field: Value" to "Field : Value". While this appeared user friendly it had many undesirable results and was quickly replaced with a simpler system (ICU + HTML). Automation like this can appear human friendly but also results in mistakes and greater complexity or cognitive load. It's hard to ever know what the result is likely to be and when it gets it wrong it might be hard to override.

If the syntax and semantics end up bound or stuck to the language and become messy as a result I'd try to see if instead those cases can be isolated out and handled specifically. The Polish number rules for example would normally be offloaded to a class dedicated to that purpose.

It's the things far more dependent on context (grammar) that's often a problem for me.

From a syntax point of view if you're thinking of using something that reads as English like basic I don't think that works well at all. It's already awkward that people translate the variable names in between {} but at least in most cases the {} format stands out as something weird and can be quickly pointed out it's something else.

Programmers write messages from scratch initially and it should be at the level they understand. Many might however find themselves naive to the needs of other languages. When composing strings in particular it's often not the case that the string is not divided in the correct places sufficiently to work with the grammar of another string.

[aphillips]

Closing this old design issue. Please open new specific issues if needed.