Page 1 of 2

Предложение по локализации

Posted: Sat 11 Apr, 2015 16:03
by Shmuel
Нынешняя система локализации (языковые файлы формата "lng"), скажем так, не идеальна.
Например, хотелось бы поддержку локализации макросов пользователя со стороны плагина LuaMacro - не получается, т.к. набор макросов у всех разный, а набор языковых файлов плагина - фиксированный.

Собственно, предложение: добавить в API плагинов одну экспортируемую функцию типа
void ProcessLanguageChangeW(const wchar_t *LanguageID) - для простоты понимания аргумент пока представлен не в виде структуры.
Плагин будет оповещаться об изменении языка, при этом он может перегрузить свои "языковые файлы" (которые могут быть любого формата, например, все языки в одном файле), либо предпринять другие действия.

Разница с существующим положением вещей: достаточно легко организовать расширяемость, даже "на лету", то-есть без перезагрузки плагина.
Мне кажется, цена за это невысока, и кода добавить в Фар надо будет совсем немного.

Предложение по локализации

Posted: Sat 11 Apr, 2015 17:05
by John Doe
Shmuel wrote: добавить в API плагинов одну экспортируемую функцию
А завтра понадобится ещё какое-нибудь оповещение, неужели ещё один экспорт заводить?
Может лучше какую-то обобщённую функцию для нотификаций?

Предложение по локализации

Posted: Sun 12 Apr, 2015 02:54
by WARP ItSelf
Вот лишь бы добавить что-нибудь.

Для начала советую вот так попробовать (подробнее в коде newarc на SVN):

Code: Select all


void ArchiveModuleManager::SetCurrentLanguage(const TCHAR* lpLanguage, bool bForce)
{
	if ( bForce || FSF.LStricmp(lpLanguage, m_strCurrentLanguage) )
	{
		for (unsigned int i = 0; i < m_pModules.count(); i++)
			m_pModules[i]->ReloadLanguage(lpLanguage);

		m_strCurrentLanguage = lpLanguage;
	}
}

void __stdcall EXP_NAME(GetPluginInfo) (
		PluginInfo *pi
		)
{
	static TCHAR *PluginConfigStrings[1];

	PluginConfigStrings[0] = _M(MPluginTitle);

	pi->PluginConfigStrings = (const TCHAR *const*)&PluginConfigStrings;
	pi->PluginConfigStringsNumber = 1;

	string strLanguage;
	apiGetEnvironmentVariable(_T("FARLANG"), strLanguage);

	pManager->SetCurrentLanguage(strLanguage);

	pi->StructSize = sizeof(PluginInfo);
}

И именно, если непонятно, сравнить в GetPluginInfo свой язык с языком Far'а (FARLANG) и что-то поменять при необходимости.

Предложение по локализации

Posted: Sun 12 Apr, 2015 07:12
by Shmuel
John Doe wrote: Может лучше какую-то обобщённую функцию для нотификаций?
"Нотификация" - это в контексте Фара просто синоним для "события". Если есть конкретная идея, как должна выглядеть эта обобщённая функция, то представьте её на рассмотрение.
WARP ItSelf wrote: И именно, если непонятно, сравнить в GetPluginInfo свой язык с языком Far'а (FARLANG) и что-то поменять при необходимости.
GetPluginInfo не вызывается во многих случаях: при нажатии клавиш (которое может активизировать макрос), при поступлении разных событий. Это не является общим решением.

Предложение по локализации

Posted: Sun 12 Apr, 2015 08:37
by John Doe
Shmuel wrote: Если есть конкретная идея, как должна выглядеть эта обобщённая функция, то представьте её на рассмотрение.
Вероятно как и прочие:

Предложение по локализации

Posted: Sun 12 Apr, 2015 09:13
by John Doe
А чего реально не хватает макросам для локализации сейчас?
GetMsg вроде бы достаточно, если каждый скрипт будет передавать свой гуид.

Остаётся как-то заставить фар загружать lng не из папки плагина (и каким-либо способом сопоставлять им гуиды).
Так может бы нам нужна сервисная функция загрузки произвольных lng?

Предложение по локализации

Posted: Sun 12 Apr, 2015 14:52
by WARP ItSelf
Ну, тут вопрос, можно ли изменить в Far'е язык так, чтобы GetPluginInfo не вызвалось. То, что он по нажатию клавиши не вызывается, это понятно.

Предложение по локализации

Posted: Sun 12 Apr, 2015 14:56
by Shmuel
WARP ItSelf wrote:можно ли изменить в Far'е язык так, чтобы GetPluginInfo не вызвалось.
В LuaMacro не вызывается, проверял.

Предложение по локализации

Posted: Sun 12 Apr, 2015 16:24
by WARP ItSelf
Я в целом вроде понял, почему так происходит. Но если добавлять новую функцию, то надо действительно одну какую-то для всех нотификаций забабахать, как я думаю. Типа Notify или OnNotify. Обсуждать надо, видимо.

2 JD:

Для Lng надо или какое-то апи по их загрузке или украсть код опять же где-нибудь в ньюарке. Их реально несложно загружать и парсить руками. Хотя единый механизм был бы правильнее, конечно.

Предложение по локализации

Posted: Sun 12 Apr, 2015 17:50
by zg
есть же ProcessSynchroEventW. название не самое удачное, но по большому счёту, какая разница?

Предложение по локализации

Posted: Sun 12 Apr, 2015 18:17
by WARP ItSelf
Ну их бы все в одну функцию запихать, конечно. Так то разница только эстетическая.

Предложение по локализации

Posted: Sun 12 Apr, 2015 18:27
by Shmuel
zg wrote: есть же ProcessSynchroEventW. название не самое удачное, но по большому счёту, какая разница?
OK для меня.

Предложение по локализации

Posted: Sun 12 Apr, 2015 18:34
by zg
WARP ItSelf wrote:Ну их бы все в одну функцию запихать, конечно. Так то разница только эстетическая.
там тип предусмотрен.

Предложение по локализации

Posted: Sun 12 Apr, 2015 19:17
by WARP ItSelf
Название несколько стремное, конечно. Но пихайте, потом как-нибудь к 4.0 переименуем и все.

Предложение по локализации

Posted: Mon 13 Apr, 2015 11:16
by John Doe
WARP ItSelf wrote: Для Lng надо или какое-то апи по их загрузке или украсть код опять же где-нибудь в ньюарке. Их реально несложно загружать и парсить руками. Хотя единый механизм был бы правильнее, конечно.
Lng очень даже просто парсить руками.
Но чем колхозить в каждом плагине, лучше бы иметь единый механизм.