When you use our Services you understand and agree:
Output may not always be accurate. You should not rely on Output from our Services as a sole source of truth or factual information, or as a substitute for professional advice.
You must evaluate Output for accuracy and appropriateness for your use case, including using human review as appropriate, before using or sharing Output from the Services.
You must not use any Output relating to a person for any purpose that could have a legal or material impact on that person, such as making credit, educational, employment, housing, insurance, legal, medical, or other important decisions about them.
Our Services may provide incomplete, incorrect, or offensive Output that does not represent OpenAI’s views. If Output references any third party products or services, it doesn’t mean the third party endorses or is affiliated with OpenAI.
Правила использования чётко говорят, что слепо доверять выдаче ни в коем случае нельзя. Если начнёт судиться, то, возможно, в показательных целях могут и лицензии лишить за некомпетентность.
Напиши комментарий о возможности распознавания человеческого авторства (а не сгенерированного ИИ) комментария «языком падонкафф»
Канэшна, ацтазри сгенерить фразу в стиле падонкафф, но распознать — чья рука (или лапа) приложилась — можна! Алгоритмы тупо копируют орфографические ошибки, а у падонкафф — целая культура с креативным п@здецом в грамматике, уместными «аффтар жжот» и историческими отсылками к Удафф-кома. ИИ не шмогёт в эту душу, ему не понять нашой искренней ржаки над «кросавчегами» и «превед-медведом». Так што, ежели коммент полон аццкого сотона и аффтарской ненависти — это 100% ручками писаный артефакт, а не бездушная нейросеть! Пеши исчо!
Просто, например, в вашей статье используются длинные тире. Является ли это маркером? А то так дойдём до того, что грамотно написанный текст будем считать ИИшным, потому что писать безграмотно — проще. (И да, это тире я набрал практически на автомате стандартным маковским хоткеем).
В канадском слоговом письме конечный c обозначается горизонтальной чертой ᐨ, поэтому для переносов необходимо использовать символ ᐀ CANADIAN SYLLABICS HYPHEN (U+1400)
Биометрия — это как если напечатать пароль на футболке и носить её везде каждый день. И менять этот самый пароль в целом нельзя или очень сложно и дорого.
То есть вы реализуете банальный вендор-лок. Причём я сомневаюсь, что ваша CMS мощнее и удобнее, чем профессиональные CAT-системы (Computer-Aided Translation), используемые переводчиками. Даже если они возьмутся за такую работу, то, скорее всего, запросят значительно больше денег.
Разрозненные переводы: разработчики работают с десятками JSON-файлов, разбросанных по проекту.
Обычно файлы локалей все лежат в одном месте. Или же разделены помодульно, если тому соответствует архитектура приложения. Здесь же вы предлагаете управлять, возможно, тысячами файлов с локалями, разбросанными по проекту.
Type safety: отсутствующие ключи или несоответствия в переводах обнаруживаются только во время выполнения.
i18next имеет встроенную проверку отсутствия ключей через типовыведение:
Владение контентом: маркетологам и другим нетехническим специалистам сложно управлять переводами без участия разработчиков.
Нет. В случае обычных файлов локалей достаточно только умения пользоваться Git. Появление новых ключей перевода определяется простым сравнением ключей дефолтной локали с другими локалями. Это можно даже вынести, например, в пайплайн тестирования релиза. В вашем случае переводчикам нужно также понимать и архитектуру приложения, и знать TypeScript, чтобы понимать, что там нагородили разработчики. Кроме того, системы автоматизации переводов скорее всего поддерживают плоские JSON с ключами-значениями, а из *.content.ts все строки придётся доставать руками и править на месте — минус автоматизация.
Предположим, мы вводим в приложение новый язык. Переводчикам (часто нанятым отдельно из специализированного агентства) предлагается бегать по всему приложению для перевода? А если они где-то забудут добавить ключ, возникнет ошибка?
Мне кажется, что в планах у Майкрософта и так было создать альтернативу Java (Хейлсберг как раз J++ первым делом разработал), то есть его и нанимали по сути для такой задачи. Даже без него они бы, вероятно, сделали что-то похожее. К C# (через Managed C++) они ушли просто потому что Sun запретил им дальнейший EEE в отношении Java. Как вариант, был бы язык, более похожий на Java, или гибрид Java и Visual Basic.
Так это же у них стратегическое решение: не создавать публично доступные графические тулкиты под конкурирующие платформы, потому что это может нести риск для самой платформы Windows.
У C# в Visual Studio на тот момент визуальный редактор был не хуже. Тем более, он фактически поддерживался из коробки в самом .NET, а потому шансов конкурировать с Майкрософтом на этом поле уже не было. Они попытались, но с их ценовой политикой шансов было немного.
Для Java Борланд с 1997 года выпускал JBuilder, но Java была и остаётся более популярна в энтерпрайзе, а не как десктопная плафторма.
Под неё, теоретически, даже copy.exe подходит
Ок, трёх человек вычитаем :)
В Google Maps можно отметить наличие полиции. Ещё есть уже готовые приложения типа Easy Ride, которые специально для этого предназначены.
Прямо даже стало интересно: это в каких же странах в принципе нет ни парковок, ни лифтов?
Правила использования чётко говорят, что слепо доверять выдаче ни в коем случае нельзя. Если начнёт судиться, то, возможно, в показательных целях могут и лицензии лишить за некомпетентность.
Если считать по аналогии с трансляцией Интервидения, то надо посчитать всех жителей всех стран, откуда можно пользоваться Максом
Канэшна, ацтазри сгенерить фразу в стиле падонкафф, но распознать — чья рука (или лапа) приложилась — можна! Алгоритмы тупо копируют орфографические ошибки, а у падонкафф — целая культура с креативным п@здецом в грамматике, уместными «аффтар жжот» и историческими отсылками к Удафф-кома. ИИ не шмогёт в эту душу, ему не понять нашой искренней ржаки над «кросавчегами» и «превед-медведом». Так што, ежели коммент полон аццкого сотона и аффтарской ненависти — это 100% ручками писаный артефакт, а не бездушная нейросеть! Пеши исчо!
Просто, например, в вашей статье используются длинные тире. Является ли это маркером? А то так дойдём до того, что грамотно написанный текст будем считать ИИшным, потому что писать безграмотно — проще. (И да, это тире я набрал практически на автомате стандартным маковским хоткеем).
В канадском слоговом письме конечный c обозначается горизонтальной чертой
ᐨ, поэтому для переносов необходимо использовать символ᐀CANADIAN SYLLABICS HYPHEN (U+1400)Так мы ответа дождёмся или только в карму минусы ставить умеете?
Биометрия — это как если напечатать пароль на футболке и носить её везде каждый день. И менять этот самый пароль в целом нельзя или очень сложно и дорого.
AI в CAT-системах тоже прикручен: https://support.crowdin.com/for-translators/#ai-assistant
То есть вы реализуете банальный вендор-лок. Причём я сомневаюсь, что ваша CMS мощнее и удобнее, чем профессиональные CAT-системы (Computer-Aided Translation), используемые переводчиками. Даже если они возьмутся за такую работу, то, скорее всего, запросят значительно больше денег.
Обычно файлы локалей все лежат в одном месте. Или же разделены помодульно, если тому соответствует архитектура приложения. Здесь же вы предлагаете управлять, возможно, тысячами файлов с локалями, разбросанными по проекту.
i18next имеет встроенную проверку отсутствия ключей через типовыведение:
https://www.i18next.com/overview/typescript
https://github.com/i18next/react-i18next/tree/master/example/react-typescript/simple
Нет. В случае обычных файлов локалей достаточно только умения пользоваться Git. Появление новых ключей перевода определяется простым сравнением ключей дефолтной локали с другими локалями. Это можно даже вынести, например, в пайплайн тестирования релиза. В вашем случае переводчикам нужно также понимать и архитектуру приложения, и знать TypeScript, чтобы понимать, что там нагородили разработчики. Кроме того, системы автоматизации переводов скорее всего поддерживают плоские JSON с ключами-значениями, а из *.content.ts все строки придётся доставать руками и править на месте — минус автоматизация.
Предположим, мы вводим в приложение новый язык. Переводчикам (часто нанятым отдельно из специализированного агентства) предлагается бегать по всему приложению для перевода? А если они где-то забудут добавить ключ, возникнет ошибка?
Мне кажется, что в планах у Майкрософта и так было создать альтернативу Java (Хейлсберг как раз J++ первым делом разработал), то есть его и нанимали по сути для такой задачи. Даже без него они бы, вероятно, сделали что-то похожее. К C# (через Managed C++) они ушли просто потому что Sun запретил им дальнейший EEE в отношении Java. Как вариант, был бы язык, более похожий на Java, или гибрид Java и Visual Basic.
Не путайте QuickBasic (с компилятором) и QBasic (урезанный интерпретатор).
Под DOS тоже был Visual Basic, да
QuickBasic делал exe, слинковывая со своим рантаймом. Что было в ранних версиях — не знаю. Позже компилятор генерировал p-code.
Пишите на Qt. Заодно будет возможность портировать программу на Linux и Mac.
Или на Avalonia, если .NET. Оно тоже кросс-платформенное и уже достаточно стабильное.
Так это же у них стратегическое решение: не создавать публично доступные графические тулкиты под конкурирующие платформы, потому что это может нести риск для самой платформы Windows.
У C# в Visual Studio на тот момент визуальный редактор был не хуже. Тем более, он фактически поддерживался из коробки в самом .NET, а потому шансов конкурировать с Майкрософтом на этом поле уже не было. Они попытались, но с их ценовой политикой шансов было немного.
Для Java Борланд с 1997 года выпускал JBuilder, но Java была и остаётся более популярна в энтерпрайзе, а не как десктопная плафторма.