crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )


  Ответ в CAT и TM
Введите ваше имя
Подтвердите код

Введите в поле код из 6 символов, отображенных в виде изображения. Если вы не можете прочитать код с изображения, нажмите на изображение для генерации нового кода.
 

Опции сообщения
 Включить смайлы?
Иконки сообщения
(Опционально)
                                
                                
  [ Без иконки ]
 


Последние 10 сообщений [ в обратном порядке ]
alex977 Дата 9.3.2013, 13:30
  OmegaT - переход на ветку 2.6. Текущая версия (она же бета) - 2.6.3.

Раскрывающийся текст
Dear All,

OmegaT standard version 2.6.3 was released.

Following version 2.5.5, OmegaT 2.6.3 is the new standard version of OmegaT.

It comes with a new updated English manual. Like the previous one, it was done
by Vito Smolej. As Vito has now resigned as documentation manager, we take the
opportunity to thank him for the huge work he has done.

Compared with 2.5.5, 2.6.3 brings 27 enhancements and some bug corrections.

The biggest improvement is the handling of team projects.
Using a standard Subversion or Git server, an unlimited number of translators
can collaborate on the same project, sharing translations and glossary entries.
The projects can be used both online and offline. When getting online again,
changes done offline are synchronised.
Read-only access to a project is also possible.

Microsoft Translator (2 million characters per month are free of charge) is now
supported. It requires setting identifiers, which can be obtained from the
Windows Azure Marketplace.

The display of the match pane is now configurable, and a “diff” display is
available, to show new and deleted text in matches. In all panes, the cursor is
now available, allowing selecting and copying text using the keyboard.

There are now markers for whitespace (space, tab, newline) and bidi-characters
in the View menu. Tag colouring now works for RTL languages/orientation. When
translating a Word (.docx) document and the target language is RTL, a number of
changes are done to the target document:
- Paragraphs, sections and tables are set to bidi.
- Runs (text elements) are set to RTL.

In addition, all spaces are now preserved in Word documents.

Validating tag now supports partial verification, where only “severe” tag
issues are reported.

It is possible to apply penalties to external TMXs, and to load a TMX as an
“alternative source”, the source segment displaying both languages. Gzipped
(.tmx.gz) TMXs are now supported.

In the list of files of the project, the encoding and the filter used are now
displayed.

Remove tags is now a project property feature, instead of being a global option

The PO filter now supports plural forms, and it is possible to ignore the
headers in the Editor.
All the changes and bug fixes are detailed in changes.txt.
Compared with the latest version 2.6.2, there are 2 enhancements: OmegaT can now
import the result of external scripts and parsing external command arguments is
more flexible.
For Git team projects, an issue was fixed with line ending on non-Windows
machines.

For this release, the Latest version 2.6.3, although labelled “beta” for
practical reasons, is exactly the same as the standard one.

You can download the new version following the directions from
http://www.omegat.org/en/downloads.html
for standard versions.


Источник

iReset Дата 25.1.2013, 22:12
 
Цитата(Litkevich Yuriy @ 25.1.2013, 22:09) *
iReset, Я чувствую заблуждение: объекты - это не файлы, которые под контролем версий. Это объекты БД на основе которой работает Git.
И в реальном хранилище объектов тьма-тьмущая.

Если ты имел в виду СУБД, то Git не использует СУБД, если, конечно, сами СУВ не считать СУБД. Все данные в Git являются объектами, файлы в том числе. В моей вырезке выше объектами были файлы.
А вообще, если честно, я уже потерял нить беседы :)
Litkevich Yuriy Дата 25.1.2013, 21:09
  iReset, Я чувствую заблуждение: объекты - это не файлы, которые под контролем версий. Это объекты БД на основе которой работает Git.
И в реальном хранилище объектов тьма-тьмущая.
ViGOur Дата 25.1.2013, 11:30
 
Цитата(iReset @ 23.1.2013, 9:59) *
ViGOur, а сколько места ты можешь выделить под репозиторий?
если нужно, то 10-20 Gb, а то и больше!
Канал 60 Mb, но из-за того, что роутер старенький делает скорость максимум 35 Mb, так что в принципе можно и Git сделать.

p.s. вы меня пинайте в личку если что, просто завал на работе, потому не всегда могу прочитать или могу прочитать и забыть, так как постоянно меня дергают...
iReset Дата 24.1.2013, 12:38
 
Цитата(Litkevich Yuriy @ 24.1.2013, 12:06) *
Пока не обнаружил подтверждения, что хранятся сами файлы.
Да, эта мысль размыта в первой половине главы. Возможно, где-то в другом месте она выражена более чётко. Пока попробую надёргать цитаты:
Цитата
Вернёмся к базе объектов в нашем тестовом репозитории.
...
Git сжал содержимое этих файлов при помощи zlib.
...
...добавим файл побольше. Добавим файл repo.rb ..., он занимает примерно 12 Кбайт:
...
Посмотрим, сколько этот объект занимает места на диске:
...
4102    .git/objects/9b/c1dc421dcd51b4ac296e3e5b6e2a99cf44391e

Теперь изменим немного данный файл и посмотрим на результат:
...
Взглянув на дерево, полученное в результате коммита, мы увидим любопытную вещь:... Теперь файлу repo.rb соответствует другой объект-блоб. Это означает, что даже одна единственная строка, добавленная в конец 400-строчного файла, требует создания абсолютно нового объекта:
4109    .git/objects/05/408d195263d853f09dca71d55116663690c27c

Итак, мы имеем два почти одинаковых объекта занимающих по 4 Кбайта на диске.


А приведённая тобой цитата относится к тому, что Git умеет сам, автоматически, переупаковывать файлы, сохраняя только изменения. И вот в этом контексте мои слова о том, что Git сохраняет полные файлы немного теряет актуальность - для конечного пользователя это уже не особенно интересно, поскольку база всё-равно маленькая. А у тебя даже меньше, чем в SVN.
Поэтому я ради академического интереса постараюсь найти другой источник информации о том, как Git хранит файлы, но для нашего вопроса это, видимо, уже не важно.

UPD: Да, наверное, правильнее было сразу давать ссылку на более раннюю главу из книги: Основы Git. Все остальные ресурсы, которые мне удалось найти, в основном, основаны на этой же книге. Вот нашел только интересное замечание, как Git упаковывает файлы - тут, т.е. дельты в Git - это совсем не патчи в SVN.
Litkevich Yuriy Дата 24.1.2013, 11:06
 
Цитата(iReset @ 23.1.2013, 10:59) *
Вот тут подробно расписано.
прочитал бегло, наткнулся на фразу:
Цитата
... Было бы неплохо, если бы Git сохранял только один объект целиком, а другой как разницу между ним и первым объектом.

Оказывается, что Git так и делает...
Пока не обнаружил подтверждения, что хранятся сами файлы.
iReset Дата 23.1.2013, 8:59
 
Цитата(Litkevich Yuriy @ 23.1.2013, 4:44) *
с чего это?
Так разработали :)

Цитата(Litkevich Yuriy @ 23.1.2013, 4:44) *
Насколько я помню обсуждения в инете, Git в отличие от SVN-а сохраняет то что выгоднее в данный момент - либо патч либо файл.
Изначально Git сохраняет целый файл. В дальнейшем он либо сам, либо по команде может преобразовать его в так называемый pack-файл, причём последний из похожих файлов останется целиковым, а более старые превращаются в патчи. Вот тут подробно расписано.

Цитата(Litkevich Yuriy @ 23.1.2013, 4:44) *
Я конечно не вникал во внутреннее устройство, но могу точно сказать хранилище Git-а для переводов у меня дома в 2 (!) раза меньше SVN-овского
Вот это ценная информация, у меня вообще нет сравнительной статистики. Если честно, я забыл, что Git в автомате иногда пакует файлы.
Тогда, может, и для сервака не будет страшно использование Git.
ViGOur, а сколько места ты можешь выделить под репозиторий?

Цитата(Litkevich Yuriy @ 23.1.2013, 4:44) *
я с SVN-а ушёл только потому, что он перестал вообще варочатся, т.е. ему не по зубам стало огромную историю держать, в отличие от Git-а.
И насколько я знаю существуют системы на основе Git-а, активно эксплуатирующие его особенность - манипуляция птчами.
Git и разработан для быстрой работы с большими проектами, насколько я знаю. Он и с ветками работает более эффективно именно за счёт того, что не изменения каждого коммита хранит, а полные файлы (по крайней мере, последние). Ну да тут я не спец.
Litkevich Yuriy Дата 23.1.2013, 3:44
 
Цитата(iReset @ 22.1.2013, 8:07) *
Проблема с git заключается в том, что для каждого коммита он сохраняет все измененные файлы целиком (не патчи), хоть и сжатые gzip.
с чего это? Насколько я помню обсуждения в инете, Git в отличие от SVN-а сохраняет то что выгоднее в данный момент - либо патч либо файл.
Я конечно не вникал во внутреннее устройство, но могу точно сказать хранилище Git-а для переводов у меня дома в 2 (!) раза меньше SVN-овского, я с SVN-а ушёл только потому, что он перестал вообще варочатся, т.е. ему не по зубам стало огромную историю держать, в отличие от Git-а.

И насколько я знаю существуют системы на основе Git-а, активно эксплуатирующие его особенность - манипуляция птчами.

П.С.
Моя история освоения Git-а
iReset Дата 22.1.2013, 15:09
 
Цитата(iReset @ 22.1.2013, 7:07) *
Надо будет проверить, можно ли будет при его использовании работать без подключения к интернету.
Проверил, ни фига не понял. На сервере однозначно сохраняются только изменения. А вот в локальной копии вроде как полные версии файлов.
Ещё возникают какие-то неприятные конфликты при корректировке перевода. OmegaT проверяет, что проект синхронизирован с сервером только при открытии. Т.е. если двое начинают параллельно переводить (открывают групповой проект), и один из них корректирует существующий перевод, то у второго он не появится, пока он принудительно не сделает update (не через OmegaT и при закрытой OmegaT), а пока этого не произойдёт, этот откорректированный перевод будет сохраняться то от одного переводчика, то от другого. Ужас, в общем.
Да и нужна ли нам такая история версий? Мне кажется, что было бы хорошо следующее: я перевел файл (или класс) и это изменение закоммитил; или я исправил перевод файла (или класса) и это изменение закоммитил; или я откорректировал перевод однотипных сегментов во всей ПП и это изменение закоммитил. Таким коммитам можно давать внятные комментарии, история версий не будет перегружена, разрешение конфликтов будет лежать на человеке, а не на программе, плюс ко всему редактору будет проще просматривать изменения, поскольку они целостные (перевод файла, корректировка файла,...). Можно будет также хранить словари, добавленные слова, игнорируемые слова, файл с информацией о файлах в переводе, т.е. то, что нужно нам, а не Омеге.
iReset Дата 22.1.2013, 8:56
 
Цитата(Алексей1153 @ 22.1.2013, 9:22) *
Чем тебе не она понравилась...
Не сама черепаха, ей я пользуюсь, и меня она более, чем устраивает.
Чем-то мне не понравилась реализация групповой работы в OmegaT в связке с SVN. С Git я просто не пробовал.
Просмотр темы полностью (откроется в новом окне)
RSS Текстовая версия Сейчас: 29.3.2024, 2:13